[Bug symtab/30265] New: [gdb/symtab] info var shows incorrect file/line combination for static const class member

[Bug symtab/30265] New: [gdb/symtab] info var shows incorrect file/line combination for static const class member

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30265

            Bug ID: 30265
           Summary: [gdb/symtab] info var shows incorrect file/line
                    combination for static const class member
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

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;
$
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30265] [gdb/symtab] info var shows incorrect file/line combination for static const class member

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30265

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
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
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30265] [gdb/symtab] info var shows incorrect file/line combination for static const class member

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30265

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30265] [gdb/symtab] info var shows incorrect file/line combination for static const class member

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30265

--- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> ---
(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.  */

...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30265] [gdb/symtab] info var shows incorrect file/line combination for static const class member

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30265

--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> ---
Created attachment 14773
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14773&action=edit
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30265] [gdb/symtab] info var shows incorrect file/line combination for static const class member

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30265

--- Comment #5 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30265] [gdb/symtab] info var shows incorrect file/line combination for static const class member

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30265

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
Submitted patch:
https://sourceware.org/pipermail/gdb-patches/2023-March/198261.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30265] [gdb/symtab] info var shows incorrect file/line combination for static const class member

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30265

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30265] [gdb/symtab] info var shows incorrect file/line combination for static const class member

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30265

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |14.1

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
Fixed by commit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.