From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DC007385841A; Wed, 29 Sep 2021 13:37:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DC007385841A From: "felix.willgerodt at intel dot com" To: gdb-prs@sourceware.org Subject: [Bug c++/28396] New: C++ template parameters are not recognized without DW_AT_name Date: Wed, 29 Sep 2021 13:37:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: c++ X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: felix.willgerodt at intel dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 13:37:25 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28396 Bug ID: 28396 Summary: C++ template parameters are not recognized without DW_AT_name Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ Assignee: unassigned at sourceware dot org Reporter: felix.willgerodt at intel dot com Target Milestone: --- Compile this sample with clang++ (I used 12.0.1): ~~~ template class Foo { public: DataT me[n]; const int me2=3Dc; }; template class Foo; int main() { Foo f; f.me[0] =3D 0; return 0; // break here } ~~~ Corresponding DWARF:=20 ~~~ 36 0x00000052: DW_TAG_class_type 37 DW_AT_calling_convention (DW_CC_pass_by_value) 38 DW_AT_name ("Foo") 39 DW_AT_byte_size (0x0c) 40 DW_AT_decl_file ("~/bin/programs/template/tt.cc") 41 DW_AT_decl_line (2) 42=20 43 0x0000005b: DW_TAG_member 44 DW_AT_name ("me") 45 DW_AT_type (0x00000097 "int[2]") 46 DW_AT_decl_file ("~/bin/programs/template/tt.cc= ") 47 DW_AT_decl_line (5) 48 DW_AT_data_member_location (0x00) 49 DW_AT_accessibility (DW_ACCESS_public) 50=20 51 0x00000068: DW_TAG_member 52 DW_AT_name ("me2") 53 DW_AT_type (0x000000b2 "const int") 54 DW_AT_decl_file ("~/bin/programs/template/tt.cc= ") 55 DW_AT_decl_line (6) 56 DW_AT_data_member_location (0x08) 57 DW_AT_accessibility (DW_ACCESS_public) 58=20 59 0x00000075: DW_TAG_template_type_parameter 60 DW_AT_type (0x000000a4 "int") 61=20 62 0x0000007a: DW_TAG_template_value_parameter 63 DW_AT_type (0x000000a4 "int") 64 DW_AT_const_value (2) 65=20 66 0x00000080: DW_TAG_template_value_parameter 67 DW_AT_type (0x000000a4 "int") 68 DW_AT_name ("c") 69 DW_AT_const_value (3) ~~~ Due to the second declaration, there is no DW_AT_name for the first two parameters. This is legal C++ (and was seen in a real project with forward declerations) and legal dwarf (DW_AT_name is optional here according to the spec). As there is no DW_AT_name, GDB won't create a symbol for the first two parameters and therefore thinks there is only one parameter (the third). See gdb/dwarf2/read.c:handle_struct_member_die(). This leads to the following bad behaviour: ~~~ (gdb) r Starting program: ~/bin/programs/template/tt.clang=20 Breakpoint 1, main () at tt.cc:15 15 return 0; // break here (gdb) pi >>> p =3D gdb.lookup_symbol('f') >>> t =3D p[0].type >>> t.template_argument(0) >>> t.template_argument(1) Traceback (most recent call last): File "", line 1, in RuntimeError: No argument 1 in template. >>> t.template_argument(2) Traceback (most recent call last): File "", line 1, in RuntimeError: No argument 2 in template. ~~~ And yes, having the compiler always emit a DW_AT_name might be the better longterm solution. But as it is legal dwarf, GDB probably should be made mo= re resiliant as well. I already looked at it a bit, and think having GDB create a symbol with a n= ame like "" (too have unique names) would be one possibile solut= ion. However I struggled a bit with adding an attribute after the DIE is already parsed. I might be able to get back to this at one point, but I thought I would ope= n a bug anyway, in case someone more experienced with dwarf2/read.c wants to ta= ke a look. Note, that https://sourceware.org/bugzilla/show_bug.cgi?id=3D15626 seems to= have the same root cause, at least at first glance. --=20 You are receiving this mail because: You are on the CC list for the bug.=