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...
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 11.2
: P2 normal
Target Milestone: 15.1
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-12-16 10:30 UTC (History)
3 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. ***
Comment 4 Sourceware Commits 2023-12-16 10:28:18 UTC
The master branch has been updated by Hannes Domani <ssbssa@sourceware.org>:


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
    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>
Comment 5 Hannes Domani 2023-12-16 10:30:32 UTC