GDB reverse execution question

GDB reverse execution question

[Carl Love]

GCC maintainers:

I am looking into some GDB regression test failures for reverse mode. 
The specific test I am currently looking at is
gdb/testsuite/gdb.reverse/step-reverse.exp.  I am running the test on a
Power 9 machine with the test compiled with two different versions of
the gcc compiler.

The test runs fine using the distro compiler /usr/bin/gcc  which is gcc
version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04).

The issue occurs with a more recent build I have gcc version 10.3.1.
where the test fails.

Both of the compilers generate the same instruction sequences but the
addresses of the assembly instructions differ slightly.  Note, the
tests are done with the default optimization for gcc.

Inintially the test executes "forward", with record enabled, thru a
couple of functions to the line in main with the label "FINISH TEST". 
The C code statement consists of five assembly instructions as shown
below where I have put in generic addresses 1 to 7 as the actuall
addresses differ slightly for the output of the two compilers:

 /* Test that "step" doesn't */                                                       
   callee();    /* STEP INTO THIS CALL */                                               
 1:   9bc:   c9 fe ff 4b     bl      884 <callee+0x8>                                        
                                                                                        
   /* Test "stepi" */                                                                   
   a[5] = a[3] - a[4]; /* FINISH TEST */     forward execution stops at this C code line       
 2:    ce 01 5f e9     lwa     r10,460(r31)   pc is here, step reverse   (distro compiler)
 3:    d2 01 3f e9     lwa     r9,464(r31)                                             
 4:    50 50 29 7d     subf    r9,r9,r10      New gcc compiler, reverse step from FINISH TEST   
                                               only gets to here not the previous       
                                               source code line                         
 5:    b4 07 29 7d     extsw   r9,r9                                                   
 6:    d4 01 3f 91     stw     r9,468(r31)    pc is here for the "newer gcc compiler"       

   callee();    /* STEPI TEST */                                                        
 7:    b1 fe ff 4b     bl      884 <callee+0x8>    

So as noted above, the distro test stops with PC at address 2 whereas
the newer gcc stops at address 6. Power used to issue groups of up to 4
instructions at a time.  Not sure that Power 9 still does that.  I am
still looking for the details on the instruction issuing on Power 9. 
But if it does still issue in groups, that could explain the difference
in the PC given the different instruction addresses.  I only mention
all this as it is something of note but I don't think is the real
problem.

The issue occurs when the test switches to reverse and then does a
step, in the reverse direction.  In the case of the distro compiler
which is at address 2, the step, in the reverse direction, stops in the
previous line of C code.  However, with the newer gcc the reverse step
from address 6 only gets to address 4 which is still in the "FINISH
TEST" C code line.  The gdb test fails because the step is not at the
"STEP INTO THIS CALL" C code line as is expected.

I have been reading the gdb code in gdb/reverse.c and gdb/record-full.c 
etc. Recording stores the register and memory changes for each executed
instruction.  What I can't find is anything that records the
association of instructions to C code lines.  So when gdb does a
reverse "step" how does it know how many assembly instructions to undo?
I believe gdb uses the debug info to figure out where the next
instruction.  Don't know where/how this is done in the forward
direction.  Again, where/how would gdb make the determination in the
reverse direction to decide where to stop?  I have not been able to
determine that in the code for doing reverse execution that I have been
studying.

The test fails because gdb doesn't unroll enough instructions to get to
the previous source line when the PC is at address 6.  I am wondering
if someone can help me understand how gdb determins where/how to stop
when doing a reverse step?  

Thanks for the help.

                           Carl Love

Re: GDB reverse execution question

[Luis Machado]

Does the following fix the problem for you?

https://sourceware.org/pipermail/gdb-patches/2021-February/175678.html

On 7/2/21 3:38 PM, Carl Love via Gdb wrote:
> GCC maintainers:
> 
> I am looking into some GDB regression test failures for reverse mode.
> The specific test I am currently looking at is
> gdb/testsuite/gdb.reverse/step-reverse.exp.  I am running the test on a
> Power 9 machine with the test compiled with two different versions of
> the gcc compiler.
> 
> The test runs fine using the distro compiler /usr/bin/gcc  which is gcc
> version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04).
> 
> The issue occurs with a more recent build I have gcc version 10.3.1.
> where the test fails.
> 
> Both of the compilers generate the same instruction sequences but the
> addresses of the assembly instructions differ slightly.  Note, the
> tests are done with the default optimization for gcc.
> 
> Inintially the test executes "forward", with record enabled, thru a
> couple of functions to the line in main with the label "FINISH TEST".
> The C code statement consists of five assembly instructions as shown
> below where I have put in generic addresses 1 to 7 as the actuall
> addresses differ slightly for the output of the two compilers:
> 
>   /* Test that "step" doesn't */
>     callee();    /* STEP INTO THIS CALL */
>   1:   9bc:   c9 fe ff 4b     bl      884 <callee+0x8>
>                                                                                          
>     /* Test "stepi" */
>     a[5] = a[3] - a[4]; /* FINISH TEST */     forward execution stops at this C code line
>   2:    ce 01 5f e9     lwa     r10,460(r31)   pc is here, step reverse   (distro compiler)
>   3:    d2 01 3f e9     lwa     r9,464(r31)
>   4:    50 50 29 7d     subf    r9,r9,r10      New gcc compiler, reverse step from FINISH TEST
>                                                 only gets to here not the previous
>                                                 source code line
>   5:    b4 07 29 7d     extsw   r9,r9
>   6:    d4 01 3f 91     stw     r9,468(r31)    pc is here for the "newer gcc compiler"
> 
>     callee();    /* STEPI TEST */
>   7:    b1 fe ff 4b     bl      884 <callee+0x8>
> 
> So as noted above, the distro test stops with PC at address 2 whereas
> the newer gcc stops at address 6. Power used to issue groups of up to 4
> instructions at a time.  Not sure that Power 9 still does that.  I am
> still looking for the details on the instruction issuing on Power 9.
> But if it does still issue in groups, that could explain the difference
> in the PC given the different instruction addresses.  I only mention
> all this as it is something of note but I don't think is the real
> problem.
> 
> The issue occurs when the test switches to reverse and then does a
> step, in the reverse direction.  In the case of the distro compiler
> which is at address 2, the step, in the reverse direction, stops in the
> previous line of C code.  However, with the newer gcc the reverse step
> from address 6 only gets to address 4 which is still in the "FINISH
> TEST" C code line.  The gdb test fails because the step is not at the
> "STEP INTO THIS CALL" C code line as is expected.
> 
> I have been reading the gdb code in gdb/reverse.c and gdb/record-full.c
> etc. Recording stores the register and memory changes for each executed
> instruction.  What I can't find is anything that records the
> association of instructions to C code lines.  So when gdb does a
> reverse "step" how does it know how many assembly instructions to undo?
> I believe gdb uses the debug info to figure out where the next
> instruction.  Don't know where/how this is done in the forward
> direction.  Again, where/how would gdb make the determination in the
> reverse direction to decide where to stop?  I have not been able to
> determine that in the code for doing reverse execution that I have been
> studying.
> 
> The test fails because gdb doesn't unroll enough instructions to get to
> the previous source line when the PC is at address 6.  I am wondering
> if someone can help me understand how gdb determins where/how to stop
> when doing a reverse step?
> 
> Thanks for the help.
> 
>                             Carl Love
> 

RE: GDB reverse execution question

[Carl Love]

On Mon, 2021-07-05 at 08:26 -0300, Luis Machado wrote:
> Does the following fix the problem for you?
> 
> https://sourceware.org/pipermail/gdb-patches/2021-February/175678.html 
> 

The patch does fix a number of the reverse regression test failures. 
However, the specific test that I am looking at, finish-reverse.exp, is
not fixed.  Here is the list of failures with and without your fix:


err file name 					no patch     louise patch
gdb.reverse/finish-reverse-bkpt.exp    		2      		2
gdb.reverse/finish-reverse.exp 			11      	11
gdb.reverse/fstatat-reverse.exp        		1       	1
gdb.reverse/next-reverse-bkpt-over-sr.exp      	2       	2
gdb.reverse/solib-precsave.exp 			17      	0
gdb.reverse/solib-reverse.exp  			17      	0
gdb.reverse/step-precsave.exp  			7       	0
gdb.reverse/step-reverse.exp   			7       	0
gdb.reverse/until-precsave.exp 			2      		2
gdb.reverse/until-reverse.exp  			1      		1

I will look a bit more into what your patch is doing and see if I can
understand what is going on in the finish-reverse.exp test with regards
to your patch.  Thanks for the help.

                                    Carl

RE: GDB reverse execution question

[Carl Love]

Louise:

> 
> The patch does fix a number of the reverse regression test failures. 
> However, the specific test that I am looking at, finish-reverse.exp,
> is
> not fixed.  Here is the list of failures with and without your fix:
> 

Sorry, I got confused.  The email I sent was for step-reverse.exp which
is fixed by your patch.  I have also been looking at finish-reverse.exp 
which is not fixed.  I got the two mixed up.  I will continue to look
at finish-reverse.exp and see what is going on with that test.

                  Carl