RE: [PATCH 1/2 version 3] fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp

[Carl Love <cel@us.ibm.com>]

Pedro:

On Tue, 2023-01-24 at 14:08 +0000, Pedro Alves wrote:
> On 2023-01-23 9:13 p.m., Carl Love wrote:
> > Pedro:
> > 
> > On Mon, 2023-01-23 at 19:17 +0000, Pedro Alves wrote:
> > > > 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.
> > > 
> > > I'd think this was on purpose.  Note that next/step/reverse-
> > > {next/step} are line-oriented
> > > stepping commands, they step/next until the previous/next line. 
> > > While "finish" is described
> > > as undoing the _function call_.
> > > 
> > > The manual says:
> > > 
> > >   reverse-finish
> > >   Just as the finish command takes you to the point where the
> > > current
> > > function returns,
> > >   reverse-finish takes you to the point where it was called.
> > > Instead
> > > of ending up at the end of
> > >   the current function invocation, you end up at the beginning.
> > > 
> > > Say you have a line with multiple statements involving multiple
> > > function calls.
> > > The simplest would be:
> > > 
> > >    func1 ();  func2 ();
> > > 
> > > Say you'd stopped inside 'func2'.  If you do finish there, in
> > > current
> > > master gdb
> > > stops at the call to 'func2', and you can then decide to reverse
> > > step
> > > into 'func1'.
> > 
> > I don't think you followed the issue.  
> 
> Totally possible!
> 
> > So, if you are in func2 and do a reverse-finish, without the patch
> > gdb
> > stops on the last instruction for the line that calls func2.  
> 
> Right.
> 
> > Now if
> > you issue a reverse-step, you stop at the first instruction for the
> > call to func2, i.e. you are still on the same source code line.  
> 
> Wait.  That right there sounds bogus.  The source line looks like:
> 
>    func1 ();  func2 ();

My bad, I didn't catch that you were implying func1 and func2 as being
on the same source line.  There is an existing bugzilla for the case of
multiple executable statements on the same line.

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

I have worked with Luis Machado <luis.machado@arm.com> on a patch to
address that issue.  We have posted a few versions of the patch but it
still needs some work for finish.  I wanted to get back to that patch
once the reverse-finish issue is done.

I need to spend some more time looking at the rest of your response to
understand everything you are talking about.  That said, my first read
looked like the issue in the bugzilla I mentioned.  The patch Luis and
I have for addressing multiple statements on the same line applies on
top of the X86 and PowerPC reverse-finish patches.  

Let me spend some more time looking at your response.  Thanks.

                      Carl 


> 
> so stepping backwards over that line should always stop at the first
> instruction of the line, not in the middle.  Let's simplify this.