Re: bfd_find_nearest_line function name return isn't mangled ?

[Daniel Berlin <dberlin at dberlin dot org>]

On Saturday, August 2, 2003, at 8:26 PM, Philippe Elie wrote:

> John Levon wrote:
> > Using binutils-2.13.90.0.2-2 on Red Hat 8 x86, application compiled 
> > with
> > Red Hat's gcc 3.2-7, reproduced on another binutils version too
> > When we're calling bfd_find_nearest_line() on the symbol
> > _Z15SelectorMatchesR17RuleProcessorDataP13nsCSSSelectoriP7nsIAtoma
> > (from Mozilla's libgklayout.so)
> > the correct filename and line number are returned. However, the
> > filled-in function name is returned as "SelectorMatches". The source
> > file is a C++ one.
> > This causes a problem for us as we need this value to avoid wrong
> > results when mixing debug and non-debug binaries.
> > Why is the function being returned as "SelectorMatches" instead of the
> > C++ mangled name ? It's a local static function to that file.
> > I suspect this has dwarf2 debugging, since objdump -g and nm | grep ' 
> > N '
> > do not work.
>
> Gcc bug I think, I opened a bug, gcc and dwarf2 debuginfo doesn't
> emit the mangled name of c++ static function #11774

Even if one were to consider this a bug, i wouldn't expect it to be 
fixed anytime soon, if ever.
We've (gcc people) have always said DW_AT_mips_linkage_name, which is 
where it's pulling the mangled name from, is going away.  The fact that 
it's starting to go away, is good, not bad.
Emitting the mangled name has been a hack/extension for gdb, which 
didn't scope DIE's properly.
You should not depend on it.
It's not actually standard DWARF2 or DWARF3, and it's going away anyway.
The proper way to construct, from DWARF2 info, the scoped method name, 
arguments, and return value is to walk the DIE tree, and paste the 
parts together, not to depend on DW_AT_mips_linkage_name.

> > This is the case for around 200 of the 1200 or so function symbols in
> > the library. A quick survey seems to indicate that it only happens for
> > file-local (static) functions.
> > Any ideas or workarounds ?
>
> we need to work-around locally with ugly things ... this bug wasn't
> in gcc 2.95 using -gdwarf-2 but it is in at least from 3.2.
>
> binutils doesn't see this bug since they ignore the
> returned value in functioname when doing:
>
> bfd_find_nearest_line(abfd, section, syms, pc,
> 			&filename, &functionname, &linenr)
>
> regards,
> Philippe Elie