[Bug gdb/28987] New: Outdated value being displayed for variable while DWARF info apparently contains the correct one

[Bug gdb/28987] New: Outdated value being displayed for variable while DWARF info apparently contains the correct one

[assaiante at diag dot uniroma1.it]

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

            Bug ID: 28987
           Summary: Outdated value being displayed for variable while
                    DWARF info apparently contains the correct one
           Product: gdb
           Version: 11.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: assaiante at diag dot uniroma1.it
  Target Milestone: ---

In this minimized C example, variable i, defined within the scope of the
function foo, has a wrong value displayed upon the call of the function test,
which is defined in an external module. To reproduce the issue, the program
should be compiled with a recent version of gcc using -O2 and the flag
-fno-tree-dce. We believe this may be a bug in gdb since debugging the same
executable file in lldb shows us the correct value. We provide an initial
analysis below on x64 and some considerations on further tests on a variant of
this code.

The following gcc bug report may also be of interest:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105007

$ cat a.c
void foo()
{ 
   int l_3 = 5, i = 0;
   for (; i < 8; i++)
       ;
   test(l_3, i);
}
int main()
{
   foo();
}
$ cat lib.c
#include <stdio.h>

void test(int l_3, int i) {
   printf("%d %d", l_3, i);
}

GCC and GDB version (GCC commit id: 500d3f0a302):
$ gcc --version
gcc (GCC) 12.0.0 20211227 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gdb --version
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

GDB trace:
$ gcc -O2 -g a.c lib.c -o unopt -fno-tree-dce
$ gdb -q unopt
Reading symbols from unopt...
(gdb) b 6
Breakpoint 1 at 0x400520: file a.c, line 6.
(gdb) r
Starting program: /home/stepping/2/reduce/unopt  

Breakpoint 1, foo () at a.c:6
6           test(l_3, i);
(gdb) info loc
l_3 = 5
i = 0

At line 6, the value of i should be 8 since the call to test() is after the for
loop that increments the variable from 0 to 8. Using a different debugger (we
tried lldb) the correct value is shown.

ASM:
0000000000400520 <foo>:
  400520:       be 08 00 00 00          mov    $0x8,%esi
  400525:       bf 05 00 00 00          mov    $0x5,%edi
  40052a:       31 c0                   xor    %eax,%eax
  40052c:       e9 0f 00 00 00          jmpq   400540 <test>
  400531:       66 2e 0f 1f 84 00 00    nopw   %cs:0x0(%rax,%rax,1)
  400538:       00 00 00 
  40053b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)

DWARF info:
0x00000070:   DW_TAG_subprogram                                                 
               DW_AT_external  (true)
               DW_AT_name      ("foo")
               DW_AT_decl_file ("/home/stepping/2/reduce/a.c")
               DW_AT_decl_line (1)
               DW_AT_decl_column       (0x06)
               DW_AT_low_pc    (0x0000000000400520)
               DW_AT_high_pc   (0x0000000000400531)
               DW_AT_frame_base        (DW_OP_call_frame_cfa)
               DW_AT_call_all_calls    (true)

0x0000008a:     DW_TAG_variable                                                 
                 DW_AT_name    ("l_3")
                 DW_AT_decl_file       ("/home/stepping/2/reduce/a.c")
                 DW_AT_decl_line       (3)
                 DW_AT_decl_column     (0x09)
                 DW_AT_type    (0x00000039 "int")
                 DW_AT_const_value     (0x05)

0x00000097:     DW_TAG_variable                                                 
                 DW_AT_name    ("i")
                 DW_AT_decl_file       ("/home/stepping/2/reduce/a.c")
                 DW_AT_decl_line       (3)
                 DW_AT_decl_column     (0x12)
                 DW_AT_type    (0x00000039 "int")
                 DW_AT_location        (0x0000001e:  
                    [0x0000000000400520, 0x0000000000400520): DW_OP_lit0,
DW_OP_stack_value
                    [0x0000000000400520, 0x0000000000400520): DW_OP_lit1,
DW_OP_stack_value
                    [0x0000000000400520, 0x0000000000400520): DW_OP_lit2,
DW_OP_stack_value
                    [0x0000000000400520, 0x0000000000400520): DW_OP_lit3,
DW_OP_stack_value
                    [0x0000000000400520, 0x0000000000400520): DW_OP_lit4,
DW_OP_stack_value
                    [0x0000000000400520, 0x0000000000400520): DW_OP_lit5,
DW_OP_stack_value
                    [0x0000000000400520, 0x0000000000400520): DW_OP_lit6,
DW_OP_stack_value
                    [0x0000000000400520, 0x0000000000400520): DW_OP_lit7,
DW_OP_stack_value
                    [0x0000000000400520, 0x0000000000400531): DW_OP_lit8,
DW_OP_stack_value)
                 DW_AT_GNU_locviews    (0x0000000c)


>From dumped DWARF info, the location of variable i is defined with different
ranges, all of them being empty except one. The only non-empty range is
[0x0000000000400520, 0x0000000000400531). As we can see from the assembly of
function foo, it covers all the function’s instructions and the value
associated to it is 8, which can be considered correct as the for loop is
optimized out and 8 is directly passed to the test function as a constant.

This issue may be related to a possible gcc bug that we found by compiling this
code at -O2 or -O3, resulting in l_3 and i not being visible when debugging. In
the involved tests, we found that providing -fno-tree-dce along with -O2
results in a binary where both variables are visible, but with the i’s value
issue pointed out here. We then found that also disabling inlining at either O2
or O3 makes both variables appear, but DWARF info may be the issue there since
lldb shows i as not available while gdb still reports 0 value.

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

[Bug gdb/28987] Outdated value being displayed for variable while DWARF info apparently contains the correct one

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-04-09
                 CC|                            |tromey at sourceware dot org
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
I can reproduce.
I see this:

(gdb) info addr i
Symbol "i" is multi-location:
  Base address 0x201140  Range 0x201140-0x201140: the constant 0
  Range 0x201140-0x201140: the constant 1
  Range 0x201140-0x201140: the constant 2
  Range 0x201140-0x201140: the constant 3
  Range 0x201140-0x201140: the constant 4
  Range 0x201140-0x201140: the constant 5
  Range 0x201140-0x201140: the constant 6
  Range 0x201140-0x201140: the constant 7
  Range 0x201140-0x201151: the constant 8
.
(gdb) p $pc
$2 = (void (*)()) 0x201140 <foo>


I think this falls into this case in dwarf2/loc.c:

      if (low == high && pc == low)
        {
          /* This is entry PC record present only at entry point
             of a function.  Verify it is really the function entry point.  */

I don't really know why this code is exactly here.
Like, it has to do with computing entry values, but I don't know
why it's needed.
If I comment out that block, this test case works.

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

[Bug gdb/28987] Outdated value being displayed for variable while DWARF info apparently contains the correct one

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hluaw at connect dot ust.hk

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
*** Bug 30278 has been marked as a duplicate of this bug. ***

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

[Bug gdb/28987] Outdated value being displayed for variable while DWARF info apparently contains the correct one

[hluaw at connect dot ust.hk]

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

--- Comment #3 from LU Hongyi <hluaw at connect dot ust.hk> ---
*** Bug 30318 has been marked as a duplicate of this bug. ***

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

[Bug gdb/28987] Outdated value being displayed for variable while DWARF info apparently contains the correct one

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Hannes Domani <ssbssa@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b45d18f19ec9507d7561c4d503a5a189214f3f77

commit b45d18f19ec9507d7561c4d503a5a189214f3f77
Author: Hannes Domani <ssbssa@yahoo.de>
Date:   Sat Dec 16 11:24:16 2023 +0100

    Use function entry point record only for entry values

    PR28987 notes that optimized code sometimes shows the wrong
    value of variables at the entry point of a function, if some
    code was optimized away and the variable has multiple values
    stored in the debug info for this location.

    In this example:
    ```
    void foo()
    {
       int l_3 = 5, i = 0;
       for (; i < 8; i++)
           ;
       test(l_3, i);
    }
    ```
    When compiled with optimization, the entry point of foo is at
    the test() function call, since everything else is optimized
    away.
    The debug info of i looks like this:
    ```
    (gdb) info address i
    Symbol "i" is multi-location:
      Base address 0x140001600  Range 0x13fd41600-0x13fd41600: the constant 0
      Range 0x13fd41600-0x13fd41600: the constant 1
      Range 0x13fd41600-0x13fd41600: the constant 2
      Range 0x13fd41600-0x13fd41600: the constant 3
      Range 0x13fd41600-0x13fd41600: the constant 4
      Range 0x13fd41600-0x13fd41600: the constant 5
      Range 0x13fd41600-0x13fd41600: the constant 6
      Range 0x13fd41600-0x13fd41600: the constant 7
      Range 0x13fd41600-0x13fd4160f: the constant 8
    (gdb) p i
    $1 = 0
    ```

    Currently, when at the entry point of a function, it will
    always show the initial value (here 0), while the user would
    expect the last value (here 8).
    This logic was introduced for showing the entry-values of
    function arguments if they are available, but for some
    reason this was added for non-entry-values as well.

    One of the tests of amd64-entry-value.exp shows the same
    problem for function arguments, if you "break stacktest"
    in the following example, you stop at this line:
    ```
    124     static void __attribute__((noinline, noclone))
    125     stacktest (int r1, int r2, int r3, int r4, int r5, int r6, int s1,
int s2,
    126                double d1, double d2, double d3, double d4, double d5,
double d6,
    127                double d7, double d8, double d9, double da)
    128     {
    129       s1 = 3;
    130       s2 = 4;
    131       d9 = 3.5;
    132       da = 4.5;
    133 ->    e (v, v);
    134     asm ("breakhere_stacktest:");
    135       e (v, v);
    136     }
    ```
    But `bt` still shows the entry values:
    ```
    s1=s1@entry=11, s2=s2@entry=12, ..., d9=d9@entry=11.5, da=da@entry=12.5
    ```

    I've fixed this by only using the initial values when
    explicitely looking for entry values.

    Now the local variable of the first example is as expected:
    ```
    (gdb) p i
    $1 = 8
    ```

    And the test of amd64-entry-value.exp shows the expected
    current and entry values of the function arguments:
    ```
    s1=3, s1@entry=11, s2=4, s2@entry=12, ..., d9=3.5, d9@entry=11.5, da=4.5,
da@entry=12.5
    ```

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28987
    Tested-By: Guinevere Larsen <blarsen@redhat.com>
    Approved-By: Tom Tromey <tom@tromey.com>

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

[Bug gdb/28987] Outdated value being displayed for variable while DWARF info apparently contains the correct one

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org
   Target Milestone|---                         |15.1
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #5 from Hannes Domani <ssbssa at sourceware dot org> ---
Fixed.

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