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

["assaiante at diag dot uniroma1.it" <sourceware-bugzilla@sourceware.org>]

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.