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

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28987

--- Comment #4 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
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>

-- 
You are receiving this mail because:
You are on the CC list for the bug.