Re: dladdr/backtrace_symbols return incorrect symbol names
Re: dladdr/backtrace_symbols return incorrect symbol names
- Subject: Re: dladdr/backtrace_symbols return incorrect symbol names
- From: Terry Lambert <email@hidden>
- Date: Tue, 24 Mar 2009 14:50:47 -0700
On Mar 24, 2009, at 9:51 AM, Ethan Tira-Thompson wrote:
On Mar 24, 2009, at 2:59 AM, Terry Lambert wrote:
Personally, I'd popen atos.
Yeah, for my own code that's what I'm going to wind up doing. For
reference, I've realized that atos's ~10 second CPU burn only occurs
for the first lookup (must be doing some kind of preprocessing of
the entire symbol table). So if I keep the atos process running,
then subsequent lookups are quite fast...
Regardless, calling out to atos seems like a hack (and is non-
portable), I'd rather dladdr worked reliably. I'm still trying to
determine whether this dladdr behavior warrants a bug report.
dladdr() is a runtime function. The non-hacky way to do this is to
use the symbolication framework, if you are an Apple employee, since
it is not a public API, or to use a tool which is linked against the
symbolication ramework, like atos.
Alternately, you can get the object file names via _dyld_image_count()
and iterate the count calling _syld_get_image_name(), and then grovel
the LC_DYSYMTAB yourself, using your own knowledge of Mac-o internals.
It's clear what is happening is dladdr is skipping all of the
't' (local text section?) symbols, and only returning the
'T' (external text section?) symbols. Spot checking the correctly
returned symbols suggests they are all 'T' symbols. I'm guessing
the 't' symbols are static-linked in the executable, and 'T' symbols
are dynamically loaded from a build directory somewhere, and thus
dladdr is only reporting the 'T' symbols as it ignores static linkage.
Does that sound right?
The 'T' symbols are external text section symbols, while the 't'
symbols are local (non-external, and therefore non-externally linkable
or callable) text section symbols. The dl* functions are interfaces
to the dynamic linker, and are expected to be used to provide runtime
linkage. Since you can't do runtime linkage of the symbols in
question, they aren't visible to the dl* routines.
One option is to not declare them static. The other option is to look
them up in the LC_DYSMTAB or use a tool that can do that lookup for
you, instead of a library routine that illegal to link to.
If so, how can I force all my symbols to be external/dynamic? I
suppose I could link everything into a .dylib and then have just
main() be in the actual executable, but perhaps there's an easier
way if I only care about development builds. Smells like ZeroLink.
Nope. You'd have to declare the functions non-static.
Alternatively, I suppose I could figure out what nm is using and
emulate that in my code... sounds even more hairy than popen atos
though, probably a bunch of manual mach-o parsing...?
Yep. See above.
Finally, it's fair that dladdr only handles dynamic symbols, but
perhaps the root issue to take up with Apple is that
backtrace_symbols should be based on something more generic that
handles static symbols as well, instead of basing it on dladdr.
They should be able to make backtrace_symbols interface with atos's
codebase instead.
Not a public API, as has been explained.
Feel free to file a bug requesting that it be made public.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden