* [Bug gdb/16678] record problem with recursion
2014-03-09 11:45 [Bug gdb/16678] New: record problem with recursion vicshen at gmail dot com
2022-10-21 10:49 ` [Bug gdb/16678] " cvs-commit at gcc dot gnu.org
@ 2022-10-21 10:49 ` cvs-commit at gcc dot gnu.org
2022-10-21 10:52 ` blarsen at redhat dot com
2023-01-25 12:27 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-21 10:49 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug gdb/16678] record problem with recursion
2014-03-09 11:45 [Bug gdb/16678] New: record problem with recursion vicshen at gmail dot com
` (2 preceding siblings ...)
2022-10-21 10:52 ` blarsen at redhat dot com
@ 2023-01-25 12:27 ` cvs-commit at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2023-01-25 12:27 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 5+ messages in thread