Bug 29927 - reverse-finish requires two reverse next instructions to reach previous source line
Summary: reverse-finish requires two reverse next instructions to reach previous sourc...
Status: CLOSED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-21 16:56 UTC by Carl E Love
Modified: 2023-01-17 16:52 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carl E Love 2022-12-21 16:56:05 UTC
Currently on X86, when executing the finish command in reverse, gdb does a
single step from the first instruction in the callee to get back to the
caller.  GDB stops on the last instruction in the source code line where
the call was made.  When stopped at the last instruction of the source code
line, a reverse next or step command will stop at the first instruction
of the same source code line thus requiring two step/next commands to
reach the previous source code line.  It should only require one step/next
command to reach the previous source code line.

By contrast, a reverse next or step command from the first line in a
function stops at the first instruction in the source code line where the
call was made.

The same behavior was observed on PowerPC.

Steps to reproduce:

gdb ./foo

execute into a function call
reverse-finish         -takes you to the caller
reverse-next           -gdb is still a the caller source line
reverse-next           -gdb moves back to the previous source line.

FYI, I have a patch to fix the issue.  Will post patch shortly.
Comment 1 Carl E Love 2023-01-11 19:08:47 UTC
The finish command when executing in reverse does not work on PowerPC correctly.  GDB doesn't stop at the caller.  It will go back to the previous breakpoint or stop when it reaches the beginning of the log file.

PowerPC has multiple entry points.  GDB does not handle them properly when doing a reverse-finish.
Comment 2 Carl E Love 2023-01-11 19:12:11 UTC
Posted two patches to the GDB mailing list to address the issues on X86 and on Power PC.

[PATCH 0/2]  fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
Date:	Wed, 11 Jan 2023 10:27:37 -0800

[PATCH 1/2]  fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
Date:	Wed, 11 Jan 2023 10:27:41 -0800
- This is the X86 fix

[PATCH 2/2]  fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
Date:	Wed, 11 Jan 2023 10:27:46 -0800
- This is the PowerPC fix
Comment 3 Sourceware Commits 2023-01-17 16:47:52 UTC
The master branch has been updated by Carl Love <carll@sourceware.org>:

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

commit b22548ddb30bfb167708e82d3bb932461c1b703a
Author: Carl Love <cel@us.ibm.com>
Date:   Mon Dec 19 12:48:54 2022 -0500

    X86: reverse-finish fix
    
    PR record/29927  - reverse-finish requires two reverse next instructions to
    reach previous source line
    
    Currently on X86, when executing the finish command in reverse, gdb does a
    single step from the first instruction in the callee to get back to the
    caller.  GDB stops on the last instruction in the source code line where
    the call was made.  When stopped at the last instruction of the source code
    line, a reverse next or step command will stop at the first instruction
    of the same source code line thus requiring two step/next commands to
    reach the previous source code line.  It should only require one step/next
    command to reach the previous source code line.
    
    By contrast, a reverse next or step command from the first line in a
    function stops at the first instruction in the source code line where the
    call was made.
    
    This patch fixes the reverse finish command so it will stop at the first
    instruction of the source line where the function call was made.  The
    behavior on X86 for the reverse-finish command now matches doing a
    reverse-next from the beginning of the function.
    
    The proceed_to_finish flag in struct thread_control_state is no longer
    used.  This patch removes the declaration, initialization and setting of
    the flag.
    
    This patch requires a number of regression tests to be updated.  Test
    gdb.mi/mi-reverse.exp no longer needs to execute two steps to get to the
    previous line.  The gdb output for tests gdb.reverse/until-precsave.exp
    and gdb.reverse/until-reverse.exp changed slightly.  The expected result in
    tests gdb.reverse/amd64-failcall-reverse.exp and
    gdb.reverse/singlejmp-reverse.exp are updated to the correct expected
    result.
    
    This patch adds a new test gdb.reverse/finish-reverse-next.exp to test the
    reverse-finish command when returning from the entry point and from the
    body of the function.
    
    The step_until proceedure in test gdb.reverse/step-indirect-call-thunk.exp
    was moved to lib/gdb.exp and renamed cmd_until.
    
    The patch has been tested on X86 and PowerPC to verify no additional
    regression failures occured.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29927
Comment 4 Sourceware Commits 2023-01-17 16:47:57 UTC
The master branch has been updated by Carl Love <carll@sourceware.org>:

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

commit 92e07580db6a5572573d5177ca23933064158f89
Author: Carl Love <cel@us.ibm.com>
Date:   Fri Jan 13 17:59:33 2023 -0500

    PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
    
    PR record/29927 - reverse-finish requires two reverse next instructions to
    reach previous source line
    
    PowerPC uses two entry points called the local entry point (LEP) and the
    global entry point (GEP).  Normally the LEP is used when calling a
    function.  However, if the table of contents (TOC) value in register 2 is
    not valid the GEP is called to setup the TOC before execution continues at
    the LEP.  When executing in reverse, the function finish_backward sets the
    break point at the alternate entry point (GEP).  However if the forward
    execution enters via the normal entry point (LEP), the reverse execution
    never sees the break point at the GEP of the function.  Reverse execution
    continues until the next break point is encountered or the end of the
    recorded log is reached causing gdb to stop at the wrong place.
    
    This patch adds a new address to struct execution_control_state to hold the
    address of the alternate function start address, known as the GEP on
    PowerPC.  The finish_backwards function is updated.  If the stopping point
    is between the two entry points (the LEP and GEP on PowerPC), the stepping
    range is set to execute back to the alternate entry point (GEP on PowerPC).
    Otherwise, a breakpoint is inserted at the normal entry point (LEP on
    PowerPC).
    
    Function process_event_stop_test checks uses a stepping range to stop
    execution in the caller at the first instruction of the source code line.
    Note, on systems that only support one entry point, the address of the two
    entry points are the same.
    
    Test finish-reverse-next.exp is updated to include tests for the
    reverse-finish command when the function is entered via the normal entry
    point (i.e. the LEP) and the alternate entry point (i.e. the GEP).
    
    The patch has been tested on X86 and PowerPC with no regressions.
Comment 5 Carl E Love 2023-01-17 16:50:51 UTC
Patch to fix issue committed, closing.
Comment 6 Carl E Love 2023-01-17 16:52:09 UTC
Issue resolved.