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: Ethan Tira-Thompson <email@hidden>
- Date: Tue, 24 Mar 2009 19:21:49 -0400
OK, thanks for helping to nail down what's going on.
I've submitted a bug to Apple, #6718509:
-------------------------------------------------------------------
When symbols are locally linked, the dladdr function on which
backtrace_symbols is based will return the nearest preceding
*external* symbol, which is often misleading, and basically renders
dladdr/backtrace_symbols useless due to unreliability.
Solutions:
A. On linux there is a -rdynamic option for gcc, specifically to
address this symbol lookup issue:
-rdynamic
Pass the flag -export-dynamic to the ELF linker, on
targets that support it. This
instructs the linker to add all symbols, not only used
ones, to the dynamic symbol
table. This option is needed for some uses of "dlopen" or
to allow obtaining
backtraces from within a program.
So we could use something similar for OS X to force the linkage of
symbols in the executable to be stored such that dladdr can find them.
B. Switch backtrace_symbols to use the 'atos' tool's codebase instead
of using dladdr. Understandably dladdr is only concerned with
dynamically loaded symbols, but it would be nice if backtrace_symbols
was more generic and could handle local/static symbols as well.
C. Open 'atos' source or publicize the "symbolication" framework so we
can emulate/customize atos functionality. popen()'ing a call to atos
is kind of ugly, but of bigger concern is that atos does some kind of
preprocessing of the entire symbol table, and for a large project like
ours this takes ~10 seconds per launch of atos. So even if we have to
stick with calling out to atos, it would be more usable if atos could
be set to only process what was needed for the trace at hand instead
of running through the entire symbol table right off the bat.
_______________________________________________
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