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

[Michael Snyder <msnyder at vmware dot com>]

Pedro Alves wrote:

> > So what should it be?  Just "error"?
>
> Ah, I think I see what's going on.  "finish" is not meaningful
> in the outermost frame, so, you'd get an error before reaching
> here, if you had no symbols.
>
>  (gdb) finish
>  "finish" not meaningful in the outermost frame.
>  (gdb) reverse-finish
>  "finish" not meaningful in the outermost frame.
>
> Is it possible to be at frame != #0 and not find a function?
>
> Wait, what does your remark about the frame #0 special
> case mean then?

This stuff makes your head spin, eh?

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.

My "special case" comment had nothing to do with frame #0.
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.

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.

As for the command name, I'm still not gonna argue about that.  ;-)
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.