[Bug gdb/16678] New: record problem with recursion

[Bug gdb/16678] New: record problem with recursion

[vicshen at gmail dot com]

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

            Bug ID: 16678
           Summary: record problem with recursion
           Product: gdb
           Version: 7.7
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: vicshen at gmail dot com

I'm having problems with ProcessRecord and recursion.
It looks like the reverse-next operation behaves like
reverse-step when dealing with a recursive method.

GNU gdb (GDB) 7.7

(gdb) l
1       int factorial(int x) {
2          if (x == 1) return 1;
3          int result = x * factorial(x-1);
4          return result;
5       }
6
7       int main() {
8           factorial(5);
9           return 0;
10      }
(gdb) start
Temporary breakpoint 1 at 0x4004a9: file a.c, line 8.
Starting program: /home/jianshen/1/a 

Temporary breakpoint 1, main () at a.c:8
8           factorial(5);
(gdb) record
(gdb) n
9           return 0;
(gdb) rn
factorial (x=2) at a.c:3
3          int result = x * factorial(x-1);
(gdb) bt
#0  factorial (x=2) at a.c:3
#1  0x0000000000400499 in factorial (x=3) at a.c:3
#2  0x0000000000400499 in factorial (x=4) at a.c:3
#3  0x0000000000400499 in factorial (x=5) at a.c:3
#4  0x00000000004004b3 in main () at a.c:8

rn should return to line 8 but it jumps to line 3 in another frame.

I searched and found Hui Zhu has once provided a patch for this issue.
See https://sourceware.org/ml/gdb/2009-03/msg00134.html
But in the latest version (7.7) it's still could be reproduced.  It might be a
missing bug.

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

[Bug gdb/16678] record problem with recursion

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Bruno Larsen <blarsen@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=49d7cd733a7f1b87aa1d40318b3d7c2b65aca5ac

commit 49d7cd733a7f1b87aa1d40318b3d7c2b65aca5ac
Author: Bruno Larsen <blarsen@redhat.com>
Date:   Fri Aug 19 15:11:28 2022 +0200

    Change calculation of frame_id by amd64 epilogue unwinder

    When GDB is stopped at a ret instruction and no debug information is
    available for unwinding, GDB defaults to the amd64 epilogue unwinder, to
    be able to generate a decent backtrace. However, when calculating the
    frame id, the epilogue unwinder generates information as if the return
    instruction was the whole frame.

    This was an issue especially when attempting to reverse debug, as GDB
    would place a step_resume_breakpoint from the epilogue of a function if
    we were to attempt to skip that function, and this breakpoint should
    ideally have the current function's frame_id to avoid other problems
    such as PR record/16678.

    This commit changes the frame_id calculation for the amd64 epilogue,
    so that it is always the same as the dwarf2 unwinder's frame_id.

    It also adds a test to confirm that the frame_id will be the same,
    regardless of using the epilogue unwinder or not, thanks to Andrew
    Burgess.

    Co-Authored-By: Andrew Burgess <aburgess@redhat.com>

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

[Bug gdb/16678] record problem with recursion

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Bruno Larsen <blarsen@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1f3e37e057e876b37db49dbd8ed5ca22c33f6772

commit 1f3e37e057e876b37db49dbd8ed5ca22c33f6772
Author: Bruno Larsen <blarsen@redhat.com>
Date:   Wed May 25 15:02:47 2022 -0300

    gdb/reverse: Fix stepping over recursive functions

    Currently, when using GDB to do reverse debugging, if we try to use the
    command "reverse next" to skip a recursive function, instead of skipping
    all of the recursive calls and stopping in the previous line, we stop at
    the second to last recursive call, and need to manually step backwards
    until we leave the first call.  This is well documented in PR gdb/16678.

    This bug happens because when GDB notices that a reverse step has
    entered into a function, GDB will add a step_resume_breakpoint at the
    start of the function, then single step out of the prologue once that
    breakpoint is hit.  The problem was happening because GDB wouldn't give
    that step_resume_breakpoint a frame-id, so the first time the breakpoint
    was hit, the inferior would be stopped.  This is fixed by giving the
    current frame-id to the breakpoint.

    This commit also changes gdb.reverse/step-reverse.c to contain a
    recursive function and attempt to both, skip it altogether, and to skip
    the second call from inside the first call, as this setup broke a
    previous version of the patch.

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

[Bug gdb/16678] record problem with recursion

[blarsen at redhat dot com]

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

B. Larsen <blarsen at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |blarsen at redhat dot com
         Resolution|---                         |FIXED

--- Comment #3 from B. Larsen <blarsen at redhat dot com> ---
those recent commits fix this issue

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

[Bug gdb/16678] record problem with recursion

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5f6ec13ffe8ae4db04419bf66868e082df73634d

commit 5f6ec13ffe8ae4db04419bf66868e082df73634d
Author: Tom de Vries <tdevries@suse.de>
Date:   Wed Jan 25 13:27:03 2023 +0100

    [gdb/testsuite] Improve leaf fn in gdb.base/unwind-on-each-insn.exp

    In test-case gdb.base/unwind-on-each-insn.exp, we stepi through function
foo
    to check various invariants at each insn, in particular hoping to excercise
    insns that modify stack and frame pointers.

    For x86_64-linux, we have a reasonably complex foo (and similar for -m32):
    ...
      4004bc:       55                      push   %rbp
      4004bd:       48 89 e5                mov    %rsp,%rbp
      4004c0:       90                      nop
      4004c1:       5d                      pop    %rbp
      4004c2:       c3                      ret
    ...
    Both stack pointer (%rsp) and frame pointer (%rbp) are modified.

    Also for s390x-linux (and similar for -m31):
    ...
    0000000001000668 <foo>:
     1000668:       e3 b0 f0 58 00 24       stg     %r11,88(%r15)
     100066e:       b9 04 00 bf             lgr     %r11,%r15
     1000672:       e3 b0 b0 58 00 04       lg      %r11,88(%r11)
     1000678:       07 fe                   br      %r14
    ...
    Frame pointer (%r11) is modified.

    Likewise for powerpc64le-linux:
    ...
    00000000100006c8 <foo>:
        100006c8:   f8 ff e1 fb     std     r31,-8(r1)
        100006cc:   d1 ff 21 f8     stdu    r1,-48(r1)
        100006d0:   78 0b 3f 7c     mr      r31,r1
        100006d4:   00 00 00 60     nop
        100006d8:   30 00 3f 38     addi    r1,r31,48
        100006dc:   f8 ff e1 eb     ld      r31,-8(r1)
        100006e0:   20 00 80 4e     blr
    ...
    Both stack pointer (r1) and frame pointer (r31) are modified.

    But for aarch64-linux, we have:
    ...
    00000000004005fc <foo>:
      4005fc:       d503201f        nop
      400600:       d65f03c0        ret
    ...
    There's no insn that modifies stack or frame pointer.

    Fix this by making foo more complex, adding an (unused) argument:
    ...
    0000000000400604 <foo>:
      400604:       d10043ff        sub     sp, sp, #0x10
      400608:       f90007e0        str     x0, [sp, #8]
      40060c:       d503201f        nop
      400610:       910043ff        add     sp, sp, #0x10
      400614:       d65f03c0        ret
    ...
    such that the stack pointer (sp) is modified.

    [ Note btw that we're seeing the effects of -momit-leaf-frame-pointer, with
    -mno-omit-leaf-frame-pointer we have instead:
    ...
    0000000000400604 <foo>:
      400604:       a9be7bfd        stp     x29, x30, [sp, #-32]!
      400608:       910003fd        mov     x29, sp
      40060c:       f9000fa0        str     x0, [x29, #24]
      400610:       d503201f        nop
      400614:       a8c27bfd        ldp     x29, x30, [sp], #32
      400618:       d65f03c0        ret
    ...
    such that also the frame pointer (x29) is modified. ]

    Having made foo more complex, we now run into the following fail on
    x86_64/-m32:
    ...
    FAIL: gdb.base/unwind-on-each-insn.exp: instruction 1: $sp_value ==
$main_sp
    ....

    The problem is that the stack pointer has changed inbetween the sampling of
    main_sp and *foo, in particular by the push insn:
    ...
     804841a:       68 c0 84 04 08          push   $0x80484c0
     804841f:       e8 10 00 00 00          call   8048434 <foo>
    ...

    Fix this by updating main_sp.

    On powerpc64le-linux, with gcc 7.5.0 I now run into PR tdep/30021:
    ...
    FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: $fba_value == $main_fba
    FAIL: gdb.base/unwind-on-each-insn.exp: insn 7: [string equal $fid
$main_fid]
    ...
    but I saw the same failure before this commit with gcc 4.8.5.

    Tested on:
    - x86_64-linux (-m64 and -m32)
    - s390x-linux (-m64 and -m31)
    - powerpc64le-linux
    - aarch64-linux

    Also I've checked that the test-case still functions as regression test for
PR
    record/16678 on x86_64.

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