Demangling of method names and addr2line/c++filt

[Andrew Haley]

Ranjit Mathew writes:
 > > So the questions seem to be:
 > > - Does addr2line (or addr2name) and dladdr always strip the leading
 > > underscore on platforms that need it stripped?
 > > If yes, then it seems save to always give a "-n" argument to c++filt.
 > 
 > I don't know about dladdr, but I did a bit of digging around in the 
 > GCC/binutils source code and found that:
 > 
 > 1. The GCC target-specific macro USER_LABEL_PREFIX essentially decides 
 >    if an underscore should be prefixed or not for labels corresponding
 >    to functions. You can see the target headers in the "gcc/config/*"
 >    folders to see which ones define this (quite a few).
 > 
 > 2. addr2line merely reports as the function name what it finds in the 
 >    symbolic debugging information in the executable. On Win32 for example,
 >    the debug info for a C function "t( )" is generated as:
 >         ...
 >         .stabs  "t:F(1,1)=(1,1)",36,0,4,_t
 >         ...
 >    So the symbolic name "t" gets associated with the assembler label "_t".
 > 
 >    AFAICT, it appears that USER_LABEL_PREFIX does not have a role to
 >    play in emitting symbolic debugging information (except of course the
 >    actual label with which the symbol is associated) and so the symbol
 >    would be free of underscores, except for those introduced by 
 >    C++/Java name mangling or those present in the "real" function name.
 > 
 >    Therefore, there's an implicit "stripping" of the leading underscore
 >    here, if you wish to see it that way.
 > 
 > 3. the situation with c++filt is slightly complex:
 > 
 >    a. the one in GCC (gcc/cp/cxxfilt.c) strips the leading underscore
 >       by default if USER_LABEL_PREFIX[0]=='_'.
 > 
 >    b. the one in binutils (libiberty/cplus-dem.c in binutils-2.13.2.1 and
 >       binutils/cxxfilt.c in the current CVS) strips the leading underscore 
 >       by default if "targ_underscore==yes" - this is true for a large
 >       number of targets as defined in "bfd/config.bfd".

Okay, so there is the origin of the bug.  When the libgcj code was
first written, gcc didn't have its own c++filt at all.

 > The following thread gives an insight into the c++filt mess:
 > 
 >     http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00271.html
 > 
 > especially this message in the thread is directly relevant to our 
 > problem:
 > 
 >     http://gcc.gnu.org/ml/gcc-patches/2002-09/msg00779.html
 > 
 > IMHO, it is safe to say since we are giving c++filt only the mangled
 > name via addr2line

But we're not, are we?  Sometimes the mangled name comes from dladdr().

 > and not the actual assembler label that is generated, we should ask
 > it to abstain from stripping any leading and incidental underscore
 > that is a part of the mangled name.
 > 
 > And though the c++filt in both binutils and GCC are supposed to be
 > developed further in lock-step, I still think it is more reliable to
 > use and recommend the one from GCC.
 > 
 > Reading the man pages for dladdr( ), I'm a bit confused about whether
 > it uses the symbolic debugging information for a shared object or the
 > exported labels (are these two necessarily separate on all targets?)

It must be the latter, because shared libraries are often stripped.

 > themselves - if it's the former, we can safely proceed with "-n" to
 > c++filt, if it's the latter *and* underscores are used on that
 > target, then we have a problem - particularly so if we get names
 > from *both* addr2line and dladdr on that target (likely).
 > 
 > My recommendation would be to use "-n" always and cross the other bridge
 > when (if ever) we get to it.

That might be okay for the trunk, but I don't want to risk breaking
stack traces on the 3.3 branch.  We haven't got time to fix it.

I still wonder if it might be much better to do the demangling in
addr2line, and this would be a much more robust solution.  Okay, so
it's broken on some targets but presubaly that's fixable.

Andrew.