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.
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.
*** Bug 30278 has been marked as a duplicate of this bug. ***
*** Bug 30318 has been marked as a duplicate of this bug. ***
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>
Fixed.