Re: bfd_find_nearest_line function name return isn't mangled ?

[Philippe Elie <phil dot el at wanadoo dot fr>]

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

> 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