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.