------- Comment #13 from dodji at gcc dot gnu dot org 2008-08-29 14:41 ------- Created an attachment (id=16162) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16162&action=view) The debug info of the program
Okay, here is a more accurate analysis. I will refer to the debug info attached. As I said in my previous comment, the foofoo variable is decribed by DIE <ec>, which is a child DIE of the DW_TAG_subprogram DIE at <c5>. <c5> is the DIE of the constructor A::A(int, int). In GDB, When I set a beakpoint in A::A(int, int) the debugger actually stops on a subprogram which DIE is <107>. This <107> DIE describes an "Out-of-Line Instance" of of A::A(int, int). So <107> rightfully has an DW_AT_abstract_origin attribute that links back to the abstract tree of A::A(int, int) at <c5>. However, foofoo does not have any DIE that is a child node of <107>. The DIE <14d> seems to be the DIE describing iii, not foofoo. That might be the reason why GDB is not finding foofoo. On the other hand, the DWARF3 specs says (in section 3.3.8.2, point 1). "An entry in the concrete instance tree may be omitted if it contains only a DW_AT_abstract_origin attribute and either has no children, or its children are omitted. Such entries would provide no useful information.". This text is at PDF page 65 (or document page 53). So by the DWARF3 spec, I would believe that the debugger should be able to walk through the DIE of the abstract tree A::A(int, int) to find the entry <ec> that describes foofoo. On the other hand, GCC could maybe play nice and generate a DIE for foofoo as a child node of the lexical block of <107>. But then maybe that would incur some dwarf bloat. Any comment ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
