With gdb-10-branch/gdb-11-branch, we have for m-static.exp: ... (gdb) info variable everywhere^M All variables matching regular expression "everywhere":^M ^M File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M 8: const int gnu_obj_4::everywhere;^M (gdb) PASS: gdb.cp/m-static.exp: info variable everywhere ... Likewise with readnow. With gdb-12-branch, we have: ... (gdb) info variable everywhere^M All variables matching regular expression "everywhere":^M ^M File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M 8: const int gnu_obj_4::everywhere;^M ^M File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M 8: const int gnu_obj_4::everywhere;^M (gdb) PASS: gdb.cp/m-static.exp: info variable everywhere ... and likewise with readnow (on ubuntu this doesn't reproduce with native, but it does with readnow). The file/line combination looks wrong: line 8 and file m-static1.cc: ... $ cat -n gdb/testsuite/gdb.cp/m-static1.cc 1 // 2002-08-16 2 3 #include "m-static.h" 4 5 const int gnu_obj_4::elsewhere = 221; $ ...
Bisects to: ... 6d263fe46e00afd8af3d609c1afd71d05eaf745e is the first bad commit commit 6d263fe46e00afd8af3d609c1afd71d05eaf745e Author: Tom Tromey <tromey@adacore.com> Date: Thu Jan 13 09:48:18 2022 -0700 Avoid bad breakpoints with --gc-sections ...
I already did commit 99d679e7b30 ("[gdb/symtab] Fix "file index out of range" complaint") to fix a problem with this commit, which limits the scope of the original fix. On current master, if I do: ... diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index c9208a097bf..b1934d26af7 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -7610,7 +7610,7 @@ handle_DW_AT_stmt_list (struct die_info *die, struct dwarf2_cu *cu, then there won't be any interesting code in the CU, but a check later on (in lnp_state_machine::check_line_address) will fail to properly exclude an entry that was removed via --gc-sections. */ - if (have_code) +// if (have_code) dwarf_decode_lines (cu->line_header, cu, lowpc, decode_mapping); } ... so effectively going back to the behaviour from before commit 6d263fe46e0, the regression disappears (not helpfully, with the current state of the test-case, the regression disappearing is shown by PASS -> FAIL, a problem that was already reported here: https://sourceware.org/pipermail/gdb-patches/2023-March/198210.html). So, at first glance it looks like the scope of the fix needs to be reduced even further.
(In reply to Tom de Vries from comment #2) > So, at first glance it looks like the scope of the fix needs to be reduced > even further. This seems to fix it: ... diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index c9208a097bf..c910be875a3 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -7610,8 +7610,7 @@ handle_DW_AT_stmt_list (struct die_info *die, struct dwarf2_cu *cu, then there won't be any interesting code in the CU, but a check later on (in lnp_state_machine::check_line_address) will fail to properly exclude an entry that was removed via --gc-sections. */ - if (have_code) - dwarf_decode_lines (cu->line_header, cu, lowpc, decode_mapping); + dwarf_decode_lines (cu->line_header, cu, lowpc, decode_mapping && have_code); } /* Process DW_TAG_compile_unit or DW_TAG_partial_unit. */ ...
Created attachment 14773 [details] Tentative patch Fix and test-case update (which applies on current trunk. I'm planning to fix the test-case first, so this patch will need updating lateron). Build and reg-tested on x86_64-linux.
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1985d8cb7048bcfce60b59cfe219d3b09bda6373 commit 1985d8cb7048bcfce60b59cfe219d3b09bda6373 Author: Tom de Vries <tdevries@suse.de> Date: Fri Mar 24 09:18:07 2023 +0100 [gdb/testsuite] Fix gdb.cp/m-static.exp regression on Ubuntu 20.04 In commit 722c4596034 ("[gdb/testsuite] Fix gdb.cp/*.exp for remote host"), I needed to change ".*/" into "(.*/)?" in: ... gdb_test "info variable everywhere" \ "File .*/m-static\[.\]h.*const int gnu_obj_4::everywhere;" ... However, due to the fact that I got this output: ... (gdb) info variable everywhere^M All variables matching regular expression "everywhere":^M ^M File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M 8: const int gnu_obj_4::everywhere;^M ^M File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M 8: const int gnu_obj_4::everywhere;^M ... I decided to make the matching somewhat stricter, to make sure that the two matched lines were subsequent. The commit turned out to be more strict than intended, and caused a regression on Ubuntu 20.04, where the output was instead: ... (gdb) info variable everywhere^M All variables matching regular expression "everywhere":^M ^M File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M 8: const int gnu_obj_4::everywhere;^M ... At that point I realized I'm looking at a bug (filed as PR symtab/30265), which manifests on openSUSE Leap 15.4 for native and readnow, and on Ubuntu 20.04 for readnow, but not for native. Before my commit, the test-case passed whether the bug manifested or not. After my commit, the test-case only passed when the bug manifested. Fix the test-case regression by reverting to the situation before the commit: pass whether the bug manifests or not. We could add an xfail for the PR, but I'm expecting a fix soon, so that doesn't look worth the effort. Tested on x86_64-linux, both on openSUSE Leap 15.4 and Ubuntu 20.04, both with native and readnow. Reported-By: Simon Marchi <simon.marchi@efficios.com>
Submitted patch: https://sourceware.org/pipermail/gdb-patches/2023-March/198261.html
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9ed6d7410c800c331d1f24051c85e4e52d7dfced commit 9ed6d7410c800c331d1f24051c85e4e52d7dfced Author: Tom de Vries <tdevries@suse.de> Date: Fri Mar 24 15:45:56 2023 +0100 [gdb/symtab] Fix line number of static const class member Since commit 6d263fe46e0 ("Avoid bad breakpoints with --gc-sections"), there was a silent regression on openSUSE Leap 15.4 for test-case gdb.cp/m-static.exp, from: ... (gdb) info variable everywhere^M All variables matching regular expression "everywhere":^M ^M File /home/vries/tmp.local-remote-host-native/m-static.h:^M 8: const int gnu_obj_4::everywhere;^M (gdb) ... to: ... (gdb) info variable everywhere^M All variables matching regular expression "everywhere":^M ^M File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static.h:^M 8: const int gnu_obj_4::everywhere;^M ^M File /data/vries/gdb/src/gdb/testsuite/gdb.cp/m-static1.cc:^M 8: const int gnu_obj_4::everywhere;^M (gdb) ... Another regression was found due to that commit, and it was fixed in commit 99d679e7b30 ("[gdb/symtab] Fix "file index out of range" complaint") by limiting the scope of the fix in the original commit. Fix this regression by yet further limiting the scope of that fix, making sure that this bit in dwarf_decode_lines is executed again for m-static1.cc: ... /* Make sure a symtab is created for every file, even files which contain only variables (i.e. no code with associated line numbers). */ ... Tested on x86_64-linux. PR symtab/30265 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30265
Fixed by commit.