From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B905A3858C52; Wed, 18 Jan 2023 21:57:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B905A3858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1674079023; bh=Jbo2qQRGupO9lLszldl1qXWgET7d1tqzTlyNRbG/mzA=; h=From:To:Subject:Date:From; b=xHSPskzA7w9Sf8m8m06iSq19WJnjtzGgPvb9DrG17Ur9AERSXB4XQEnLzkEnWdleQ e3E23a4+LhKSZjDFGwOfoOkAefYwebIR8uo/7+0r7vBXbebex8ki17Pofz5igDYMCB ubBMekkpIi7hc2g7nVCTt/R3tIgTmn3LQYEB9DN0= From: "dblaikie at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug c++/30023] New: Support template base names in gdb_index Date: Wed, 18 Jan 2023 21:57:03 +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: dblaikie at gmail 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 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30023 Bug ID: 30023 Summary: Support template base names in gdb_index Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ Assignee: unassigned at sourceware dot org Reporter: dblaikie at gmail dot com Target Milestone: --- I recently implemented a new feature/option in Clang, -gsimple-template-nam= es, which causes Clang to produce DWARF for C++ templates (class and function) = with the base name (eg: "t1") only, instead of including the template parameters (eg: "t1"). The template parameters are described by the DW_TAG_template_*_parameter DIEs and full human-readable names can be rebui= lt from those, the same as is done for the namespaces the template is within, = or the type of a function. (side note: GCC already uses simple names for alias templates, but doesn't include template parameters: (eg: "template using z =3D y; z= var;" produces a DW_TAG_typedef named "z" with no template parameters (but = the DW_AT_type correctly refers to "y") and for variable templates (also missing template parameters): https://godbolt.org/z/WKvc3oxah - no mentions= of "T1" and "V1" here - presumably just bugs, but may raise interesting questi= ons about moving towards simplified template names more generally. Clang (without -gsimple-template-names) matches GCC in using the simple name for the variable template - but includes the DW_TAG_template_*_parameter. C= lang uses the unsimplified name for the alias template ("y") but does not include a DW_TAG_template_*_parameter... ) In any case - all this mostly works, but gdb's index handling doesn't cope = well with this situation - specifically, if the index includes the simplified na= me, gdb doesn't resolve the type from declaration to definition across files. Incidentally loading in the CU containing the definition does cause GDB to = link the decl and definition correctly. Here's an example: a.h ``` template struct demo_type_templ { int member; }; demo_type_templ *get_d(); ``` a.cpp: ``` #include "a.h" int main() { demo_type_templ *d =3D get_d(); return 0; } ``` b.cpp: ``` #include "a.h" demo_type_templ *get_d() { static demo_type_templ d =3D {3}; return &d; } ``` ``` $ clang++ -ggnu-pubnames -fuse-ld=3Dlld -Wl,--gdb-index a.cpp b.cpp -g -o d= emo -gsimple-template-names=20 $ gdb -batch -ex "b 4" -ex r -ex "ptype *d" -ex "quit" ./demo``` ... Breakpoint 1, main () at a.cpp:4 4 return 0; type =3D struct demo_type_templ { } ``` Without the index: ``` Breakpoint 1, main () at a.cpp:4 4 return 0; type =3D struct demo_type_templ [with T =3D int] { T member; } ``` If I compare the index created from Clang (via -ggnu-pubnames/lld -Wl,--gdb-index) with the one generated by `gdb-add-index`: ``` --- good.txt 2023-01-18 21:52:29.705950886 +0000 +++ bad.txt 2023-01-18 21:52:11.917974796 +0000 @@ -1,11 +1,11 @@ .gdb_index - Version : 0x00000008 + Version : 0x00000007 CU list offset : 0x00000018 Address area offset : 0x00000038 Symbol table offset : 0x00000038 Constant pool offset: 0x00002060 - section size : 0x000020a4 + section size : 0x000020b4 CU list. array length: 2 format: [entry#] cuoffset culength [ 0] 0x00000000 0x00000051 [ 1] 0x00000051 0x0000005f @@ -20,8 +20,11 @@ Symbol table: length 1024 format: [entry#] symindex cuindex [type] "name= " or=20 format: [entry#] "name" , list of cuindex [ty= pe] [ 106] 1 [global function(3) ] "get_d" - [ 196] 1 [global type(1) ] "demo_type_templ" + [ 258] 1 [global type(1) ] "demo_type_templ" [ 489] 0 [global function(3) ] "main" - [ 754] 0 [static type(1) ] "int" + [ 754] "int" + 0 [static type(1) ] + 1 [static type(1) ] + [ 973] 1 [static var-enum(2) ] "get_d::d" ``` So, a few differences, but presumably the critical one is the name for the template instantiation. Clang could be made to produce the unsimplified name for ggnu-pubnames, but that'd regress some of the space savings of this mode & it'd be nice to have some more consistency between DW_AT_name and index entry. It'd be also good to agree on this between clang/gcc/gdb/lldb especially for DWARFv5 .debug_names so that those are generally usable. The way this was addressed in lldb was to do a fallback query - query with = the unsimplified name if that's what's available, then try again with the simplified name (& prune the results based on the DIEs returned). That way = both full and simplified names can be supported and mixed to some degree - so lo= ng as the index matches the content it's indexing (eg: an index entry "t1" sho= uld go to a DIE named "t1", an index entry "t1" should go to a DIE named "t1") --=20 You are receiving this mail because: You are on the CC list for the bug.=