OProfile

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

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
>

On Sun, Aug 03, 2003 at 09:10:08AM -0400, Daniel Berlin wrote:

> You should not depend on it.

We're merely depending on libbfd returning a sensible string.

> 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.

Is there any hope of libbfd doing this then ? The current return value
from bfd_find_nearest_line() is particularly misleading. I think it's
reasonable to call it a bug, even if it lies in binutils and not gdb.

thanks,
john

-- 
Khendon's Law:
If the same point is made twice by the same person, the thread is over.

Hi John,

>> 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.
>
> Is there any hope of libbfd doing this then ?

Only if someone volunteers to write the necessary code.  (I am not
volunteering since I am swamped with other things at the moment).


> The current return value from bfd_find_nearest_line() is
> particularly misleading. I think it's reasonable to call it a bug,
> even if it lies in binutils and not gdb.

I would suggest that the best thing to do, if you do not want to fix
the bug yourself, is to submit a testcase that can be added to the
linker or binutils testsuite.  That way we will be reminded that this
bug exists and that it needs to be fixed.

Cheers
        Nick