[Bug debug/37982] Extraneous DW_TAG_variable tag
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-11-01 11:03:52 |2010-03-18 12:52:49 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #10 from dodji at gcc dot gnu dot org 2010-03-18 12:53 --- Bug no more present in 4.5 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #9 from dodji at gcc dot gnu dot org 2010-03-17 21:15 --- The situation has change quite a lot since gcc 4.3.0. Now a DW_TAG_member is emitted for the static member variable, and only one DW_TAG_variable is emitted to represent the variable definition. So I guess the bug can be closed now? With 4.5 I get this: 0b: Abbrev Number: 1 (DW_TAG_compile_unit) c DW_AT_producer: (indirect string, offset: 0x62): GNU C++ 4.5.0 20100301 (experimental) 10 DW_AT_language: 4(C++) 11 DW_AT_name: (indirect string, offset: 0x0): class.c 15 DW_AT_comp_dir: (indirect string, offset: 0x19): /home/dodji/devel/git/gcc-branches.git/gcc-PR37982.git/prtests 19 DW_AT_low_pc : 0x4004b4 21 DW_AT_high_pc : 0x4004c0 29 DW_AT_stmt_list : 0x0 12d: Abbrev Number: 2 (DW_TAG_structure_type) 2e DW_AT_name: A 30 DW_AT_byte_size : 1 31 DW_AT_decl_file : 2 32 DW_AT_decl_line : 2 33 DW_AT_sibling : 0x49 237: Abbrev Number: 3 (DW_TAG_member) 38 DW_AT_name: (indirect string, offset: 0x58): elsewhere 3c DW_AT_decl_file : 2 3d DW_AT_decl_line : 3 3e DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8): _ZN1A9elsewhereE 42 DW_AT_type: 0x49 46 DW_AT_external: 1 47 DW_AT_declaration : 1 [...] 0a0: Abbrev Number: 1 (DW_TAG_compile_unit) a1 DW_AT_producer: (indirect string, offset: 0x62): GNU C++ 4.5.0 20100301 (experimental) a5 DW_AT_language: 4(C++) a6 DW_AT_name: (indirect string, offset: 0x8d): class2.c aa DW_AT_comp_dir: (indirect string, offset: 0x19): /home/dodji/devel/git/gcc-branches.git/gcc-PR37982.git/prtests ae DW_AT_low_pc : 0x4004c0 b6 DW_AT_high_pc : 0x4004c0 be DW_AT_stmt_list : 0x46 1c2: Abbrev Number: 2 (DW_TAG_structure_type) c3 DW_AT_name: A c5 DW_AT_byte_size : 1 c6 DW_AT_decl_file : 1 c7 DW_AT_decl_line : 2 c8 DW_AT_sibling : 0xde 2cc: Abbrev Number: 3 (DW_TAG_member) cd DW_AT_name: (indirect string, offset: 0x58): elsewhere d1 DW_AT_decl_file : 1 d2 DW_AT_decl_line : 3 d3 DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8): _ZN1A9elsewhereE d7 DW_AT_type: 0xde db DW_AT_external: 1 dc DW_AT_declaration : 1 [...] 1ea: Abbrev Number: 6 (DW_TAG_variable) eb DW_AT_specification: 0xcc ef DW_AT_decl_file : 2 f0 DW_AT_decl_line : 2 f1 DW_AT_location: 9 byte block: 3 ac 5 40 0 0 0 0 0 (DW_OP_addr: 4005ac) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #8 from swagiaal at redhat dot com 2008-12-01 16:12 --- DW_AT_MIPS_linkage_name should be removed from GCC only after the DW_AT_name scoping/qualification will get fully fixed. GDB currently already contains the DW_AT_MIPS_linkage_name reader and there is probably no need to disable it (except for testing purposes). Agreed. My patch fixes test cases where DW_AT_MIPS_linkage_name was not generated by gcc, but the patch should be smarter about falling back on DW_AT_MIPS_linkage_name when the correct canonical name cannot be constructed. On GDB CVS HEAD for gdb.cp/m-static.exp a command `print gnu_obj_4::elsewhere' works for me as it can find (presumably) the corrent .symtab mangled symbol. Sure it would be good to get DW_AT_name fixed in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #6 from swagiaal at redhat dot com 2008-11-28 16:33 --- (2) Defining declaration 86 should point by DW_AT_specification to its non-defining declaration 37. (The DWARF citation is here from Dodji.) (But I do not see these two problems as real issues for debugging.) I ran into this issue because gdb was only reading die 0x86 for variable 'elsewhere' (I have not looked into why). The problem is that without proper scoping on an abstract_origin attribute, so the correct canonical name for this variable cannot be constructed (without relying on DW_AT_MIPS_linkage_name that is). Therefore a 'print A::elsewhere' command fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #7 from jan dot kratochvil at redhat dot com 2008-11-29 00:23 --- (In reply to comment #6) I ran into this issue because gdb was only reading die 0x86 for variable 'elsewhere' (I have not looked into why). The problem is that without proper scoping on an abstract_origin attribute, so the correct canonical name for this variable cannot be constructed (without relying on DW_AT_MIPS_linkage_name that is). Therefore a 'print A::elsewhere' command fails DW_AT_MIPS_linkage_name should be removed from GCC only after the DW_AT_name scoping/qualification will get fully fixed. GDB currently already contains the DW_AT_MIPS_linkage_name reader and there is probably no need to disable it (except for testing purposes). On GDB CVS HEAD for gdb.cp/m-static.exp a command `print gnu_obj_4::elsewhere' works for me as it can find (presumably) the corrent .symtab mangled symbol. Sure it would be good to get DW_AT_name fixed in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #5 from jan dot kratochvil at redhat dot com 2008-11-28 01:36 --- (In reply to comment #4) First, I think the DIE representing the defining declaration of A::elsewhere in class2.c should have a DW_AT_specification pointing back to the DIE representing the declaration or A::elsewhere in class.h. Already present: non-defining declaration is cf, the defining declaration is ed. ed properly points by DW_AT_specification to its cf. Second, I think the DIE of the defining declaration of A::elsewhere in class2 should have a DW_AT_const_value attribute whose value should be the constant 211. This can be deduced from the dwarf2 spec, section [4.1 Data Object Entries], point 9, pdf page 35, spec page 33 that reads: 9. An entry describing a variable whose value is constant and not represented by an object in the address space of the program, or an entry describing a named constant, does not have a location attribute. DW_AT_const_value is more for Fortran constants which are an equivalent of C #define. In the sample code here `static const int' is in .rodata, it has its address (DW_AT_location) and can be tracked by `rwatch' (read-watchpoint). [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [15] .rodata PROGBITS 00400658 0658 0014 A 0 0 8 Symbol table '.symtab' contains 73 entries: Num:Value Size TypeBind Vis Ndx Name 55: 00400668 4 OBJECT GLOBAL DEFAULT 15 _ZN1A9elsewhereE It should be sufficient the type entry at 0xe1 (not shown in the sample dump here) is already correctly DW_TAG_const_type. And third, as you pointed out, the DIE of the declaration of A::elsewhere should not appear twice in the class.c compilation unit. It should only appear once, in the scope of the A class. Two vs. one DIE is not a mistake but more a minor optimization (such optimization is already Bug debug/37941). With single DIE it would look OK to me. With two DIEs there are currently these problems: (1) DW_AT_name is now `elsewhere' while it should be either `A::elsewhere' or whole DW_TAG_variable should be enclosed by DW_TAG_class_type for `A'. It may be Bug c++/37590. (Non-standard DW_AT_MIPS_linkage_name should be removed in the future.) (2) Defining declaration 86 should point by DW_AT_specification to its non-defining declaration 37. (The DWARF citation is here from Dodji.) (But I do not see these two problems as real issues for debugging.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
[Bug debug/37982] Extraneous DW_TAG_variable tag
--- Comment #4 from dodji at gcc dot gnu dot org 2008-11-01 11:03 --- I could reproduce this on 4.3 and trunk (4.4). Actually I think there are several problems here. First, I think the DIE representing the defining declaration of A::elsewhere in class2.c should have a DW_AT_specification pointing back to the DIE representing the declaration or A::elsewhere in class.h. That can be deduced from the dwarf2 spec, section [4.1 Data Object Entries], point 5, pdf page 35, spec page 33 that reads: 5. If the variable entry represents the defining declaration for a C++ static data member of a structure, class or union, the entry has a DW_AT_specification attribute, whose value is a reference to the debugging information entry representing the declaration of this data member. The referenced entry will be a child of some class, structure or union type entry.. Second, I think the DIE of the defining declaration of A::elsewhere in class2 should have a DW_AT_const_value attribute whose value should be the constant 211. This can be deduced from the dwarf2 spec, section [4.1 Data Object Entries], point 9, pdf page 35, spec page 33 that reads: 9. An entry describing a variable whose value is constant and not represented by an object in the address space of the program, or an entry describing a named constant, does not have a location attribute. Such entries have a DW_AT_const_value attribute, whose value may be a string or any of the constant data or data block forms, as appropriate for the representation of the variables value. The value of this attribute is the actual constant value of the variable, represented as it would be on the target architecture. And third, as you pointed out, the DIE of the declaration of A::elsewhere should not appear twice in the class.c compilation unit. It should only appear once, in the scope of the A class. -- dodji at gcc dot gnu dot org changed: What|Removed |Added CC||dodji at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-01 11:03:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37982
