Add find_symbol_and_addr, which also returns the symbol base address

[noamraph]

Hi,

I'm writing some analysis tool that uses addr2line - thanks a lot for it!

It turns out that I also need to find the symbol containing an address. Loader.find_symbol() gives me the name, but I also need the symbol address.

Will it be possible to add a method that also returns the address? One alternative is to return Option<(&str, u64)>, as what is currently in this branch, and another alternative is to return Option<&SymbolMapName>, both are fine with me.

Thanks!
Noam

[philipc]

Thanks for the PR. We don't want to return SymbolMapName because we want to avoid object in the public API.

It seems that if you want this for symbols, then you probably want this for frames too? For example, we may have DWARF for a particular function, but no symbol for it.

[noamraph]

@philipc I assume that something similar can be added for frames, it's just that I haven't used frames at all.

BTW, I now think that find_symbol_and_addr is a confusing name, since it sounds like it returns the address of the argument, instead of the argument of the symbol.

One alternative, which I think results in the easiest-to-understand API, is to just change find_symbol to return the symbol name and address. However, I don't know if you'd like this backwards-incompatibility.

If you prefer to keep find_symbol as it is, I think that find_symbol2 or find_symbol_name_and_symbol_address are better names than find_symbol_name_and_addr.

[philipc]

How about returning a struct Symbol that contains the name and address. This allows us to document clearly what the values being returned mean, with the possibility of adding more fields in future (e.g. symbol type). The function can be called something like find_symbol_info. Ideally the current find_symbol would have been called find_symbol_name but I don't think a breaking change is worth it for this.

[noamraph]

@philipc I like that! What do you think of the updated code?

[philipc]

Thanks!