Re: [RFA] Reverse Debugging, 5/5

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 02 Oct 2008 14:40:51 -0700
> From: Michael Snyder <msnyder@vmware.com>
> CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>, 
>  "drow@false.org" <drow@false.org>,
>  "pedro@codesourcery.com" <pedro@codesourcery.com>, 
>  "teawater@gmail.com" <teawater@gmail.com>
> 
> >> +  case EXEC_ERROR:
> >> +  default:
> >> +    fprintf_filtered,  (out,
> >> +                     _("Target `%s' does not support execution-direction."),
> >> +                     target_shortname);
> >> +    break;
> > 
> > Why print an error message? isn't it better to say the direction is
> > "forward" (which is documented as the default in your patch for the
> > manual)?
> 
> Maybe.  I'm open to discussion.
> 
> The context is, the user says "show exec-direction"
> with a target that doesn't support reverse.
> 
> Is it better to just say "Forward", with no comment,
> or is it better to let the user know that the question
> is not applicable?  Or both?

Both, I'd say.

> >> +  if (dir == EXEC_REVERSE)
> >> +    error (_("Already in reverse mode.  Use '%s' or 'set exec-dir forward'."),
> >> +        cmd);
> > 
> > Isn't it better to silently do the equivalent of "cmd"?
> 
> Possibly.  Again, I'm open to discussion.  But I think
> we've discussed this one before

Well, at least I'm consistent... ;-)

> > ALL side effects?  I thought some of them cannot be undone,
> > un-outputting to the various I/O devices etc.
> 
> That depends on the implementation on the target side.
> For instance, VMware's implementation can undo device I/O,
> so long as the device is virtual, but gdb-freeplay cannot.
> 
> GDB has no way of knowing this, but perhaps I should say
> something more explicit about it in the doc?

Yes.

> >>                                                         Starting from
> >> +the first line of a function, @code{reverse-next} will take you back
> >> +to the caller of that function, @emph{before} the function was called.
> > 
> > Shouldn't we have some kind of caveat here regarding function prologue
> > and epilogue?
> 
> Like what?
> 
> If I've done my job right, prologues and epilogues
> should be handled transparently, just like they are
> when stepping forward.

Are they treated transparently when we step forward?  I had an
impression that in optimized code, they aren't always transparent.