Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Johan Rydberg <jrydberg@virtutech.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: dan@shearer.org, gdb@sources.redhat.com
Subject: Re: [discuss] Support for reverse-execution
Date: Fri, 20 May 2005 12:22:00 -0000	[thread overview]
Message-ID: <428DD67E.2030507@virtutech.com> (raw)
In-Reply-To: <01c55d27$Blat.v2.4$69471120@zahav.net.il>

Eli Zaretskii wrote:

>>What I have done is add a new variable, step_direction, that can either
>>be STEP_DIR_FORWARD or STEP_DIR_REVERSE. 
> 
> I'd prefer STEP_FORWARD and STEP_BACKWARD.

Ok.

>>To implement "rnext" I had to add a new target-specific function that
>>tries to figure out the address of the call instruction based on the
>>last executed instruction and the instruction to be executed, IF the
>>current instruction can be identified as a return insn.
>  
> Sorry, I'm confused.  Isn't it right that if I'm stepping backwards
> through code such as this:
> 
>     i += 1;
>     foo (i);
>   =>i = 0;
> 
> where "=>" shows the current source line, then typing `rnext' once
> will get me to this:
> 
>     i += 1;
>   =>foo (i);
>     i = 0;
> 
> which means I'm now before the CALL insn that calls `foo'?  If so,
> what ``return insn'' were you talking about?  If it's the return
> instruction that returns from `foo', then that insn is inside the code
> generatedfor `foo', which GDB won't see.  What am I missing?

When you're single stepping backwards you can end up almost anywhere
in the code.  Take this scenario (in pseudo-PPC-assembler):

(1)  foo (i);
      0:   80 7f 00 08     lwz     r3,8(r31)
      4:   48 00 00 01     bl      X <foo>
      8:                   nop
(2)  i = 0;
      c:   38 00 00 00     li      r0,0
     10:   90 1f 00 08     stw     r0,8(r31)

<foo>:
     ....
     4c:   4e 80 00 20     blr

You start with PC = c, and single steps backwards.  You end up on
the nop-insn.  This is inside the single step range of line 1. So
you single step another instruction backwards, and suddenly you
stop at PC = 4c, which is far outside the stepping range.  To detect
if this was due to a "return from subroutine" you inspect the current
instruction, blr, and if it happens to be return insn you can deduct
the address of the call insn that called "foo". Since PowerPC does
not have any delay slots, it's "safe" to assume that the insn _before_
the LAST stop_pc (== prev_pc) is the call insn.

So to skip the subroutine call, you set a breakpoint on 0x4
(prev_pc - 4 = 8 - 4 = 4) and do a reverse-continue.  When the
breakpoint hits, you continue stepping until you reach the start
of the stepping range.


>>+  add_com ("rnext", class_run, rnext_command,
>>+           "Step program until it reaches the previous source line.\n\
> 
> "Go backwards until the program reaches the source line before the
> current one."

Ok.

> 
>>+   add_com_alias ("rn", "rnext", class_run, 1);
> 
> Do we want another alias called "previous"?

I think so, and maybe also "prev" and/or "pre".

>>+extern enum step_direction_kind step_direction; 
> 
> Yuk! a global variable!

I though it was OK since other variables in this context
are global, such as step_range_start and step_frame_id.

>>+      if (step_direction == STEP_DIR_FORWARD)
>>+	target_resume (resume_ptid, step, sig);
>>+      else
>>+	{
>>+	  target_reverse (resume_ptid, step);
>>+	} 
> 
> I'd prefer that target_resume accepted the direction argument.  Is
> there something that I'm missing that makes this hard or impossible?

I don't think so.  You just need to update more targets, though.

~j


  parent reply	other threads:[~2005-05-20 12:22 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19  1:23 Dan Shearer
2005-05-19 13:01 ` Johan Rydberg
2005-05-19 13:18   ` Daniel Jacobowitz
2005-05-19 13:47     ` Johan Rydberg
2005-05-20 10:37   ` Eli Zaretskii
2005-05-20 11:37     ` Andreas Schwab
2005-05-20 13:18       ` Daniel Jacobowitz
2005-05-20 13:36         ` Fabian Cenedese
2005-05-20 13:47           ` Daniel Jacobowitz
2005-05-20 14:41       ` Eli Zaretskii
2005-05-20 22:14         ` Daniel Jacobowitz
2005-05-20 12:22     ` Johan Rydberg [this message]
2005-05-20 13:19       ` Daniel Jacobowitz
2005-05-20 14:12       ` Eli Zaretskii
2005-05-20 13:14     ` Daniel Jacobowitz
2005-05-20 14:34       ` Eli Zaretskii
2005-05-20 15:40       ` Johan Rydberg
2005-05-20 10:47 ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2005-05-21 15:53 Paul Schlie
2005-05-20 22:11 Michael Snyder
2005-05-20 23:32 ` Paul Schlie
2005-05-20 21:59 Michael Snyder
2005-05-20 21:51 Michael Snyder
2005-05-21  9:44 ` Eli Zaretskii
2005-05-20 21:44 Michael Snyder
2005-05-20 21:25 Michael Snyder
2005-05-20 21:16 Michael Snyder
2005-05-20 21:31 ` Daniel Jacobowitz
2005-05-21  9:39 ` Eli Zaretskii
2005-05-23 18:19   ` Michael Snyder
2005-05-20 21:11 Michael Snyder
2005-05-20 21:27 ` Daniel Jacobowitz
2005-05-20 19:02 Michael Snyder
2005-05-20 20:43 ` Eli Zaretskii
2005-05-20 21:03   ` Michael Snyder
2005-05-20 15:49 Paul Schlie
2005-05-20 17:41 ` Dan Shearer
2005-05-20 22:01   ` Paul Schlie
2005-05-20 22:08     ` Daniel Jacobowitz
2005-05-20 22:43       ` Paul Schlie
2005-05-21  0:58         ` Daniel Jacobowitz
2005-05-21  1:42           ` Paul Schlie
2005-05-21  1:53             ` Daniel Jacobowitz
2005-05-21  1:56               ` Daniel Jacobowitz
2005-05-21 15:03                 ` Paul Schlie
2005-05-21 14:13               ` Paul Schlie
2005-05-21 14:23                 ` Daniel Jacobowitz
2005-05-21 15:04                   ` Paul Schlie
2005-05-20 20:58 ` Michael Snyder
2005-05-20 21:35   ` Paul Schlie
2005-05-16 17:47 Dan Shearer
2005-05-16 18:04 ` Dan Shearer
2005-05-20 18:15 ` Daniel Jacobowitz
2005-05-21  0:05   ` Frank Ch. Eigler
2005-05-21 10:13     ` Eli Zaretskii
2005-05-21 10:28       ` Russell Shaw
2005-05-21 12:38         ` Eli Zaretskii
2005-05-21 12:55           ` Russell Shaw
2005-05-21 14:39           ` Russell Shaw
2005-05-21 14:19       ` Daniel Jacobowitz
2005-05-21 15:46         ` Eli Zaretskii
2005-05-21 17:43           ` Daniel Jacobowitz
2005-05-23 19:39             ` Dan Shearer
2005-05-12 23:08 Michael Snyder
2005-05-13  6:23 ` Eli Zaretskii
2005-05-19 13:46   ` Daniel Jacobowitz
2005-05-19 18:46     ` Michael Snyder
2005-05-19 19:26       ` Johan Rydberg
2005-05-20 10:55     ` Eli Zaretskii
2005-05-20 13:04       ` Daniel Jacobowitz
2005-05-20 14:30         ` Eli Zaretskii
2005-05-20 14:43           ` Andreas Schwab
2005-05-20 20:48         ` Michael Snyder
2005-05-20 20:51           ` Daniel Jacobowitz
2005-05-20 20:38     ` Michael Snyder
2005-05-20 15:05 ` Vladimir Prus
2005-05-20 15:58   ` Eli Zaretskii
2005-05-20 18:14     ` Daniel Jacobowitz
2005-05-20 18:30       ` Eli Zaretskii
2005-05-20 19:27   ` Stan Shebs

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=428DD67E.2030507@virtutech.com \
    --to=jrydberg@virtutech.com \
    --cc=dan@shearer.org \
    --cc=eliz@gnu.org \
    --cc=gdb@sources.redhat.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