Add function context and readback structures with related functions ##r2sleigh

[0verflowme]

• Mark this if you consider it ready to merge
• I've added tests (optional)
• I wrote some lines in the book (optional)

Description

[trufae]

some manual review comments here

[trufae]

From opus:

🟠 Readback/context use fcn->callconv instead of the persisted signature state

r_anal_function_readback_collect() and r_anal_function_context_collect() copy fcn->callconv, but r_anal_str_to_fcn() and DWARF imports persist func.<name>.cc in sdb_types without synchronizing the live RAnalFunction. These new APIs can therefore return a stale/default calling convention unless callers manually patch fcn->callconv first.

Suggested Fix

Resolve the canonical function name through the existing type lookup path and read the calling convention from sdb_types (for example via r_anal_cc_func()), then add a test that only parses/imports a signature and verifies the readback value.

{"target":{"filePath":"libr/anal/fcn.c","range":{"startLine":2306,"endLine":2391}}}

🟠 anal_function_signature_realname() forks the existing name-normalization logic

The new helper strips import prefixes and leading __, but the type system already centralizes broader function-name resolution in r_type_func_name() / r_type_func_guess(). Keeping a second, narrower normalization path means context_collect, readback_collect, and apply_signature can disagree with the rest of the type system on names such as sym.imp.__isoc99_*, __GI_*, or dll_*.

Suggested Fix

Reuse the canonical resolver instead of open-coding a new normalization helper, so every signature path shares the same lookup behavior and there is only one place to maintain these heuristics.

{"target":{"filePath":"libr/anal/fcn.c","range":{"startLine":2306,"endLine":2391}}}

🟡 r_anal_function_apply_signature() is not atomic on failure

The function clears the old signature entries before it knows the replacement can be built, so any later allocation failure returns false after partially deleting or rewriting the existing prototype. That adds another half-written error path and makes the new API harder to reason about.

Suggested Fix

Build the replacement keys/values first and only clear/commit once every allocation has succeeded, or stage the update in a temporary structure and swap it in at the end.

{"target":{"filePath":"libr/anal/fcn.c","range":{"startLine":2306,"endLine":2391}}}