Support `.callers` and other `Function` methods for extern functions

[saruman9]

What is the feature you'd like to have?
I'd like extern (imported) functions to be fully represented as Function objects (or at least to have a wrapper/interface that behaves similarly), so that I can use standard API methods and properties like .callers, .caller_sites, etc. For example, I'd expect bv.get_functions_by_name("strcpy") to return the extern function if it's present in the binary.

Is your feature request related to a problem?
Yes. Currently, extern functions (such as those from standard libraries) are represented differently in the MLIL (e.g., as MediumLevelILExternPtr in the dest field of MediumLevelILCall). Because of this, I cannot interact with them using the same APIs available for regular functions. As a result, methods like .callers and .caller_sites do not work for them. There also seems to be no straightforward way to get call sites to extern functions without iterating through all IL instructions in all functions manually.

Are any alternative solutions acceptable?
If exposing extern functions as regular Function objects is not feasible, I would appreciate an alternative API that allows querying for call sites to extern functions by name or address, without needing to manually walk through every function's IL.

Additional Information:
This feature would improve the developer experience when writing plugins or analyses that rely on detecting uses of unsafe or critical extern functions like strcpy, malloc, or system.

This might be related to or similar to issue #2663.

[saruman9]

I’ve found an alternative approach that works:

s = bv.get_symbols_by_name("strcpy")[0]
caller_sites = bv.get_callers(s.address)

If you feel that adding full support for Function-like methods on extern functions isn’t strictly necessary for consistency, feel free to consider this issue resolved.

[saruman9]

Additionally, I noticed that current_function.callees returns an empty list when the function only calls external functions, while current_function.callee_addresses is non-empty in the same case.

I understand why this happens, but it was a bit confusing — I didn’t expect that behavior and only discovered it by chance.