public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Luis Machado <luis.machado@linaro.org>
To: Carl Love <cel@us.ibm.com>, gdb@sourceware.org
Cc: Rogerio Alves <rogealve@br.ibm.com>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Subject: Re: GDB reverse execution question
Date: Mon, 5 Jul 2021 08:26:40 -0300	[thread overview]
Message-ID: <0581aed7-5fbb-4764-d6fa-ac6a0573044e@linaro.org> (raw)
In-Reply-To: <2915ed3bce4756d4b6291ae3bf84a8b4a9ce67a7.camel@us.ibm.com>

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
> 

  reply	other threads:[~2021-07-05 11:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-02 18:38 Carl Love
2021-07-05 11:26 ` Luis Machado [this message]
2021-07-06 20:53   ` Carl Love
2021-07-06 21:08     ` Carl Love

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0581aed7-5fbb-4764-d6fa-ac6a0573044e@linaro.org \
    --to=luis.machado@linaro.org \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.ibm.com \
    --cc=gdb@sourceware.org \
    --cc=rogealve@br.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).