From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic303-20.consmr.mail.ir2.yahoo.com (sonic303-20.consmr.mail.ir2.yahoo.com [77.238.178.201]) by sourceware.org (Postfix) with ESMTPS id ADB503857C71 for ; Thu, 7 Apr 2022 15:16:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ADB503857C71 X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649344596; bh=z3OE1zmHjgfjr1VL//eemRDowh/PwpXOLMivJ7NQsVf=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=YN9NLXesvFu410vbt09g6+U2UPYThT/DOEvDEgESL3NW4b/KUwEm4/sN7RRDj5/PKW4+6n4WmKRVTwD1I5umwVaKD0TR7O+zoOAE9RMdERN/PHwhVf4uOTaQ2D8ydmZAXmnSm5lT8QRQrdb2ZH59JmbEAqeqNWa3boRpHeRBbxFYxm7r3mOZetZ1W80zy/Yo6aUpurMdVVr1bFP1USDMxRnW4j5CUdHlTGBKgO3imrNqSanp3uJbC+hkVf3ndlmt2G1OWpn8CzVd/59Cdo39JP4+mR3+MNGMt6Lxy1z+Mx6kAieu6iHJ4MqkAuaBG+U2wfpylblS0ms3f4fhz+5REA== X-YMail-OSG: hEdJFf8VM1le_NJkJsJHaRPoCEfVgCgMFOuoMcF4qwP4o3N1Deoy7hAWLqWytPT 4P3f5PeGUxjNu7FAvgpuANo6OnYCf8CZN1MbAnu2JHD8XZZiwuRGr8l9QXy7.QXPsggSHG7s7rZ4 p8D3s7lif9_F2DOoghgVgzwukGWmmTxioST6Vz2Owt0flZkNn2fS6lcMlP2RqhZJKkvnBfJDDyiT X8g5l0Cf3LHo_lURXohi39oQjHMGMo4kIBKkOARqUeHaF95.F6_8i_tjxxUIYvCz.gsiTltKfAld dYreOea.lbwahkCdC.3gPMEixRmE1LnLJ0cdz_Q8cw5P1seoeoB8ygUrsk1p26p9Hc4c664xsp2k Zfat3Rlxt_OvoSQ7c.Lym6qed.Ir4HR51G_CmHCIKMSFtiZbLquN7tTINi4ohZNlMm3R8JFV0u6b zrH3RCJdcU5WHiU2OXVMdp2eOvb.10Ui7PLVqL4aVXNmC4Q89N77kSUZJZ0NCc0iCTIBN_Lx0cGw LoJ9urFQDNE2HkmJeUwvSsbO4DkwwuU1OUQiOCqzFMfHhJOLgoMHJUDeMQxMTje6WHTW_A0XL9.f jkXuHlwfT_9i7qFzfoJL9HvaTccCe_puveOMYfeNjG9dKU8YGVfA5ZdYHQiUoAcKtfMRfq18fy89 KfDGcfInIj2VW9DYqJJYmvA0JZYsS7XDm7619y5ymmLDVBRUSi1vRRHs2RCB_sWbXkT1EMYkZTMf tXbPS8T6ZhRpMPYzNy5fYzx06523PSRgGUbEu7KROLuSEqHnvVNMB1ZexwwfO9NVbODyt_BiAAzl yXTeB08y8lgl7sAi98TV9sAxkQSI70MA.zC0sRAaxE9QFgWf0MN3jcdS65RQycbl.w4cvjmzed.c w4HVyOB3yOmE1TJWsS5SHsV4Is0o.m2LwrYM_zmqmaTxU1chR2HlJ7HN3q6Gm5bLsvgxOlXtavmn BtLNg61znxUBjbie2PzIubeoqUIhmM8zmnjRaZTIMCwnmnyjVLbwJjk6r9W4kV_zuzg2OyqlpxpE SKpjG6CXitAJuf0kvzm2SyPZEsvDU9aNN1Yztr.5dAEkIGGIybG4Pd0XfeUQP38NNWJOQLE7WoqP eorBy_PS_6jvuv.haiDunrpx3sVuTTbt7v_peM0VjGJXFLOaL6QG4j0J9Lnd7UTLl1HUPeiFJp7u fTQJmIaD3CbA36VejF759zSpolMKeiDDTwK5w01cSSnFekJTeMrTfV6MRlT7_mta5RwHMOZE.t0g amU0927aBY5TVbkMUWv9NQRCHxIRGuiIBJdSF9DB.McGRI5o2agfplQM6wgUrU8TlUm.sJyACwF3 8SKnzdspdPFJsUOo2X0gGj.zA5i9IIAi0Hr6hIPrSWgAPv4.o..GWnxtgLycaVtB9YwRGpiXy0MX WQsEpnOiLpvDbmRzckO2Yc6jYBSJOy4aY8ImVlvzXgBSTXb6oJWEJhm_A1Wqy2n8AKbTKWbw_JRE gNM6yUh9dwFM7RxuVhXUo_icA3IW3yndLS1Az6wGFDSljROmqqr05KpCkSXynDDwut67Hrhqeva4 cszt9fSb8hyaOOydlXs1eBL0dRG.V.Mq8AQf3hWji8YkPiDBcRGW7wlnhM2h6WYl9m3r8QJneWxl wf4wbsqI4j_VyC_YlxAAX2O6iA9vUZbF1BOntfmiqPbXJEGLKsOfG7GFpEezUsKbjijF3VJc1ZVv r6w2tAA_4zQA3QVodBp73hD6gBaPedVru38q96HUeQAj.53yqkBezFgmlJUN6k.QED5f5KqGWi5S YZKxz5hJgE0re6j0t.ky6.OVJG2LXgKYQ04w81P33R89zQOOQ5jrh8bVn_6uWBP_tNDY2rWWzHyy roCKc7HhmQ3aCeIpH5ySsBTug3jXwMnlq9_0NEqv3E0YUN9QfpKReQCmKm8Fzs6hGLXUvIoaZQVz kd1ELdF56XR7QVZOjYwVqEB5oODcNOCG3MOeU_ijN6GoJ2EJO.m5sJ1CdlH1xtVSPVicsK_SuatB znNPPaUyBC4Nq3nMUXknuBP68GgwbzGYvBf3bYZQkwBnNDx8OkAdqS8VLRhJNP2KHrWKV3MUtoQW OOcYBpLhYUL7d694sH15Icne8GbX397znNQaIqcNf7es1ym2djJ3OOZKWIJGhTzFTp7QhulCccfH DvMyvNbIZOl5lgJgcB_5684ZBgCxew22Y3wnXLne7XsFF67OLvkDiu3go1NjnkWySlLscn96R6_R ZvLZx4IZPtj6z14Sivl6vxy98eBwb5uTD X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ir2.yahoo.com with HTTP; Thu, 7 Apr 2022 15:16:36 +0000 Date: Thu, 7 Apr 2022 15:19:19 +0000 (UTC) From: Hannes Domani To: "gdb-patches@sourceware.org" , Simon Marchi Message-ID: <1505314165.4339353.1649344759459@mail.yahoo.com> In-Reply-To: <20220407015159.1734834-6-simon.marchi@polymtl.ca> References: <20220407015159.1734834-1-simon.marchi@polymtl.ca> <20220407015159.1734834-6-simon.marchi@polymtl.ca> Subject: Re: [PATCH 5/6] gdb: prepend comp_dir to symtab name in buildsym_compunit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20001 YMailNorrin X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 15:16:39 -0000 Am Donnerstag, 7. April 2022, 03:55:39 MESZ hat Simon Marchi via Gdb-patch= es Folgendes geschrieben: > Printing macros defined in the main source file doesn't work reliably usi= ng > various toolchains, especially when DWARF 5 is used.=C2=A0 For example, u= sing either > of these binaries: > >=C2=A0=C2=A0=C2=A0=C2=A0 $ gcc --version >=C2=A0=C2=A0=C2=A0=C2=A0 gcc (GCC) 11.2.0 >=C2=A0=C2=A0=C2=A0=C2=A0 $ ld --version >=C2=A0=C2=A0=C2=A0=C2=A0 GNU ld (GNU Binutils) 2.38 >=C2=A0=C2=A0=C2=A0=C2=A0 $ gcc test.c -g3 -gdwarf-5 > >=C2=A0=C2=A0=C2=A0=C2=A0 $ clang --version >=C2=A0=C2=A0=C2=A0=C2=A0 clang version 13.0.1 >=C2=A0=C2=A0=C2=A0=C2=A0 $ clang test.c -gdwarf-5 -fdebug-macro > > I get: > >=C2=A0=C2=A0=C2=A0=C2=A0 $ ./gdb -nx -q --data-directory=3Ddata-directory = a.out >=C2=A0=C2=A0=C2=A0=C2=A0 (gdb) start >=C2=A0=C2=A0=C2=A0=C2=A0 Temporary breakpoint 1 at 0x111d: file test.c, li= ne 6. >=C2=A0=C2=A0=C2=A0=C2=A0 Starting program: /home/simark/build/binutils-gdb= -one-target/gdb/a.out > >=C2=A0=C2=A0=C2=A0=C2=A0 Temporary breakpoint 1, main () at test.c:6 >=C2=A0=C2=A0=C2=A0=C2=A0 6=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 retur= n ZERO; >=C2=A0=C2=A0=C2=A0=C2=A0 (gdb) p ZERO >=C2=A0=C2=A0=C2=A0=C2=A0 No symbol "ZERO" in current context. > > When starting to investigate this (taking the gcc-compiled binary as an > example), we see that GDB fails to look up the appropriate macro scope > when evaluating the expression.=C2=A0 While stopped in > macro_lookup_inclusion: > >=C2=A0=C2=A0=C2=A0=C2=A0 (top-gdb) p name >=C2=A0=C2=A0=C2=A0=C2=A0 $1 =3D 0x62100011a980 "test.c" >=C2=A0=C2=A0=C2=A0=C2=A0 (top-gdb) p source.filename >=C2=A0=C2=A0=C2=A0=C2=A0 $2 =3D 0x62100011a9a0 "/home/simark/build/binutil= s-gdb-one-target/gdb/test.c" > > `source` is the macro_source_file that we would expect GDB to find.=C2=A0= But > it doesn't find it because the filename it is looking for isn't exactly > like the filename as written in the macro_source_file object. > > The `name` parameter comes from the symtab::filename field of the symtab > we are stopped at.=C2=A0 The symtab's filename comes from the compilation > unit's DW_AT_name, passed to the buildsym_compunit's constructor: > >=C2=A0=C2=A0 https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec58= 0cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/read.c#L10627-10630 > > The name is used as is to create the main subfile of the compunit, which > eventually becomes a symtab.=C2=A0 In this case it is just the filename, > "test.c". > > The name of the macro_source_file comes from the line number program > header's file table, from the call to the line_header::file_file_name > method: > >=C2=A0=C2=A0 https://gitlab.com/gnutools/binutils-gdb/-/blob/4815d6125ec58= 0cc02a1094d61b8c9d1cc83c0a1/gdb/dwarf2/macro.c#L54-65 > > line_header::file_file_name prepends the directory path the file is > relative to, if the file name is not absolute.=C2=A0 In this case, the fi= le > name is "test.c", appended to the directory > "/home/simark/build/binutils-gdb-one-target/gdb". > > Because the symtab's name is not created the same way as the > macro_source_file's name is created, we get this mismatch. > > This patch fixes things locally in a rather naive way by making > buildsym_compunit format the main subfile's name the same way as the > DWARF reader formats the main name, that is by prepending the directory > part.=C2=A0 Since this changes some symtab names, there is some user-visi= ble > changes when those names are output, as can be seen from the few tests I > needed to update.=C2=A0 The difference is that some symtab names that > previously didn't include a directory portion will now include one. > > Finally, change the comment above the line_header::file_file_name > declaration.=C2=A0 The part about it returning a name relative the > compilation directory is just not true, it thought it was very > misleading.=C2=A0 There isn't much we can guarantee about how the returne= d > file name will look like, because it depends on what the compiler > decided to put in the file and directory tables. > > Change-Id: I0372906dafc01d6b3774b2ab72f9d28d7069b6cc > --- > gdb/buildsym.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | 15 +++++++++++++++ > gdb/dwarf2/line-header.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 5 +---- > gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp=C2=A0 |=C2=A0 2 +- > gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl |=C2=A0 2 +- > 4 files changed, 18 insertions(+), 6 deletions(-) > > diff --git a/gdb/buildsym.c b/gdb/buildsym.c > index 4718b201f036..c1c588a869dc 100644 > --- a/gdb/buildsym.c > +++ b/gdb/buildsym.c > @@ -71,6 +71,21 @@ buildsym_compunit::buildsym_compunit (struct objfile *= objfile_, >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 non-primary symtabs.=C2=A0 It is also= needed by get_macro_table.=C2=A0 */ >=C2=A0=C2=A0 m_compunit_symtab =3D allocate_compunit_symtab (m_objfile, na= me); > > +=C2=A0 std::string name_copy; > + > +=C2=A0 /* In order not to lose the line information directory, > +=C2=A0=C2=A0=C2=A0 we concatenate it to the filename when it makes sense= . > +=C2=A0=C2=A0=C2=A0 Note that the Dwarf3 standard says (speaking of filen= ames in line > +=C2=A0=C2=A0=C2=A0 information): ``The directory index is ignored for fi= le names > +=C2=A0=C2=A0=C2=A0 that represent full path names''.=C2=A0 Thus ignoring= dirname in the > +=C2=A0=C2=A0=C2=A0 `else' branch below isn't an issue.=C2=A0 */ > + > +=C2=A0 if (!IS_ABSOLUTE_PATH (name) && m_comp_dir !=3D nullptr) > +=C2=A0=C2=A0=C2=A0 { > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name_copy =3D string_printf ("%s/%s", m_c= omp_dir.get (), name); > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name =3D name_copy.c_str (); > +=C2=A0=C2=A0=C2=A0 } > + >=C2=A0=C2=A0 /* Build the subfile for NAME (the main source file) so that = we can record >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a pointer to it for later. >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IMPORTANT: Do not allocate a struct s= ymtab for NAME here. > diff --git a/gdb/dwarf2/line-header.h b/gdb/dwarf2/line-header.h > index 8fb44be56b2e..845fbebfa8d3 100644 > --- a/gdb/dwarf2/line-header.h > +++ b/gdb/dwarf2/line-header.h > @@ -162,10 +162,7 @@ struct line_header >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 header.=C2=A0 These point into dwarf2= _per_objfile->line_buffer.=C2=A0 */ >=C2=A0=C2=A0 const gdb_byte *statement_program_start {}, *statement_progra= m_end {}; > > -=C2=A0 /* Return file name relative to the compilation directory of file > -=C2=A0=C2=A0=C2=A0 number I in this object's file name table.=C2=A0 The = result is > -=C2=A0=C2=A0=C2=A0 allocated using xmalloc; the caller is responsible fo= r freeing > -=C2=A0=C2=A0=C2=A0 it.=C2=A0 */ > +=C2=A0 /* Return file name of file number FILE in this object's file nam= e table.=C2=A0 */ >=C2=A0=C2=A0 gdb::unique_xmalloc_ptr file_file_name (int file) const= ; > >=C2=A0=C2=A0 private: > diff --git a/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp b/gdb/tests= uite/gdb.dwarf2/dw2-objfile-overlap.exp > index 2257dd228191..6ea68e1f997f 100644 > --- a/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp > +++ b/gdb/testsuite/gdb.dwarf2/dw2-objfile-overlap.exp > @@ -45,4 +45,4 @@ gdb_breakpoint "*outer_before" > > # FAIL was: > # No line number information available for address 0x4 > -gdb_test "info line inner" {Line 2 of "inner\.c" starts at address .*} > +gdb_test "info line inner" {Line 2 of "/tmp/inner\.c" starts at address = .*} > diff --git a/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl b/gdb/test= suite/gdb.dwarf2/imported-unit-bp.exp.tcl > index fe92c530888d..d2a74c5031b1 100644 > --- a/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl > +++ b/gdb/testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl > @@ -126,4 +126,4 @@ if { [prepare_for_testing "failed to prepare" ${testf= ile} \ > gdb_reinitialize_dir /tmp > > # Using an absolute path is important to see the bug. > -gdb_test "break /tmp/${srcfile}:19" "Breakpoint .* file $srcfile, line .= *" > +gdb_test "break /tmp/${srcfile}:19" "Breakpoint .* file /tmp/$srcfile, l= ine .*" > > -- > 2.35.1 I came up with a different fix: --- a/gdb/dwarf2/line-header.c +++ b/gdb/dwarf2/line-header.c @@ -69,7 +69,11 @@ line_header::file_file_name (int file) const =C2=A0=C2=A0=C2=A0=C2=A0 { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const file_entry *fe =3D file_name_at = (file); -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!IS_ABSOLUTE_PATH (fe->name)) +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* The directory index 0 always means the c= ompilation directory. +=C2=A0=C2=A0 =C2=A0 For DWARF 4 and before because 0 means DW_AT_comp_dir,= and +=C2=A0=C2=A0 =C2=A0 for DWARF 5 because the first entry of the directory t= able is +=C2=A0=C2=A0 =C2=A0 the compilation directory.=C2=A0 */ +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!IS_ABSOLUTE_PATH (fe->name) && fe->d_i= ndex > 0) =C2=A0=C2=A0=C2=A0 =C2=A0{ =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 const char *dir =3D fe->include_dir (this); =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 if (dir !=3D NULL) But there is probably a good reason why you didn't choose this variant. Regards Hannes