Re: [PATCH v4 2/2] gdb/reverse: Fix stepping over recursive functions

[Bruno Larsen <blarsen@redhat.com>]

On 25/10/2022 16:55, Simon Marchi wrote:
> On 10/5/22 06:38, Bruno Larsen via Gdb-patches wrote:
>> 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.
>> ---
>>   gdb/infrun.c                                |  2 +-
>>   gdb/testsuite/gdb.reverse/step-precsave.exp |  6 ++-
>>   gdb/testsuite/gdb.reverse/step-reverse.c    | 19 ++++++-
>>   gdb/testsuite/gdb.reverse/step-reverse.exp  | 55 +++++++++++++++++++--
>>   4 files changed, 74 insertions(+), 8 deletions(-)
> Hi Bruno,
>
> I see these failures since this commit:
>
>      $ make check TESTS="gdb.reverse/step-reverse.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
>      FAIL: gdb.reverse/step-reverse.exp: reverse next over recursion again
>      FAIL: gdb.reverse/step-reverse.exp: enter recursive function
>      FAIL: gdb.reverse/step-reverse.exp: step over recursion inside the recursion
Hi Simon,

Sorry about the delay in responding to this, took me a while to track it 
down.

This was actually a latent bug, not a regression. If you try to run 
gdb.reverse/step-reverse in the native-gdbserver setup manually, then 
run the following commands:

(gdb) tbreak main
(gdb) record
(gdb) until 61
(gdb) rn 2
(gdb) n

You'll see the same failures. After the final next we should be stopped 
at line 58, and we end up on line 61 instead.

This happens because when recording the instruction call, GDB doesn't 
seem to save the stack change, only registers, so when reconstructing 
the state we aren't aware that the return address changes. This makes it 
so when setting the breakpoint at the return address, we set it to the 
return of the second callee return, instead of the first callee in this 
case (or recursive_callee in the case you found).

I hope this explanation made sense...

Cheers,
Bruno

>
> Simon
>