Bug 28987 - Outdated value being displayed for variable while DWARF info apparently contains the correct one
Summary: Outdated value being displayed for variable while DWARF info apparently conta...
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 11.2
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
: 30278 30318 (view as bug list)
Depends on:
Reported: 2022-03-21 19:44 UTC by Assaiante Cristian
Modified: 2023-04-06 17:58 UTC (History)
2 users (show)

See Also:
Last reconfirmed: 2022-04-09 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Assaiante Cristian 2022-03-21 19:44:45 UTC
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()
$ 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

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

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.
Comment 1 Tom Tromey 2022-04-09 15:17:57 UTC
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.
Comment 2 Tom Tromey 2023-03-27 20:48:46 UTC
*** Bug 30278 has been marked as a duplicate of this bug. ***
Comment 3 LU Hongyi 2023-04-06 17:58:36 UTC
*** Bug 30318 has been marked as a duplicate of this bug. ***