[Bug c++/17720] New: Function names appear without namespace/class prefixes in backtrace for optimized code

["martin.galvan at tallertechnologies dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17720

            Bug ID: 17720
           Summary: Function names appear without namespace/class prefixes
                    in backtrace for optimized code
           Product: gdb
           Version: 7.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: c++
          Assignee: unassigned at sourceware dot org
          Reporter: martin.galvan at tallertechnologies dot com

Created attachment 8017
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8017&action=edit
The code I'm testing this bug with

If we have the following code:

#include <stdio.h>

class myClass {
public:
    void method() { puts("Hello world!"); }
};

int main()
{
    myClass instance;
    instance.method();

    return 0;
}

When we compile it with gcc 4.9.2 without optimizations, a backtrace inside
method() will show us this:

(gdb) bt
#0  myClass::method (this=0x7fffffffdcef) at test.cpp:5
#1  0x0000000000400541 in main () at test.cpp:11

However, if we compile it with -O1 and further, backtracing from an instruction
belonging to the (now inlined) method() will show us this:

(gdb) bt
#0  method (this=<synthetic pointer>) at test.cpp:5
#1  main () at test.cpp:11

which doesn't have the class name prefix. The same happens with namespaces.

The debug info emmited by gcc seems to be correct, and it includes the full
name of the method (for any optimization level):

$ objdump --dwarf=info test | c++filt
...
 <2><2a1>: Abbrev Number: 15 (DW_TAG_subprogram)
    <2a2>   DW_AT_external    : 1    
    <2a2>   DW_AT_name        : (indirect string, offset: 0x373e): method    
    <2a6>   DW_AT_decl_file   : 1    
    <2a7>   DW_AT_decl_line   : 5    
    <2a8>   DW_AT_linkage_name: (indirect string, offset: 0x1480):
myClass::method()    
    <2ac>   DW_AT_accessibility: 1    (public)
    <2ad>   DW_AT_declaration : 1    
    <2ad>   DW_AT_object_pointer: <0x2b1>
...

I think the problem may be somewhere inside dwarf2read.c (perhaps in
determine_prefix()?).

-- 
You are receiving this mail because:
You are on the CC list for the bug.