Re: [RFA] Resubmit reverse debugging [4/5]

[Pedro Alves <pedro at codesourcery dot com>]

On Thursday 09 October 2008 03:46:58, Michael Snyder wrote:
> Pedro Alves wrote:

> > Wait, what does your remark about the frame #0 special
> > case mean then?
> 
> This stuff makes your head spin, eh?

Yeah, spins in reverse.

> OK, so this is the inverse of the example that I posted for Joel
> (about stepping into a function backward).  This is "what happens
> if I say "finish" and I'm going backward?"
> 
> So consider the function:
> 
> 18: int foo (int a)
> 19: {
> 20:    return a + 1;
> 21: }
> 
> Now if I'm at line 20 and I want to finish forward, I have to
> find the caller, set a bp AFTER the call, run to it, then
> extract the return value for printing.
> 
> If I want to "reverse-finish", I still find the caller, but
> now I want to set a breakpoint BEFORE (or at) the call insn.
> I'm going to execute backward thru the call, rather than
> execute forward thru the return.

Thanks for the explanations.

Ok, I had understood that correctly then. 

> My "special case" comment had nothing to do with frame #0.

Ok, it's probably too late here to be thinking, but I found this
frame #0 reference confusing:

+  Note that this can only happen at frame #0, since there's
+  no way that a function up the stack can have a return address
+  that's equal to its entry point.  */

> The special case is that, if I happen to be starting from
> the first instruction of the callee (the label or entry point),
> then there is no need to set a breakpoint.  I can just do
> a singlestep, and that will take me to the caller.
> 

Yep, that I got too.  That's what I was refering to when
I mentioned a "begin" command.  A "begin" would do:

- execute backward until I'm at the start of the function
  (after prologue)
- If I want to go to the caller (like your finish), I do
  another reverse "step" or "next".

No need for the extra single-step special case,

> Also, when I am going backward, there is no return value
> for me to extract when I get back to the caller, since the
> callee is not returning.

Or this special case.

> As for the command name, I'm still not gonna argue about that.  ;-)

So, it wasn't just about the command name.  ;-)

> I just figured that a logical starting place would be, we have to
> know what we're going to do in the case of each existing command
> if we need to do it backward.

Ok.

Thanks again for the explanations.

-- 
Pedro Alves