Re: [RFA] Reverse debugging, part 3/3: user interface / docs

[Daniel Jacobowitz <drow at false dot org>]

On Thu, Apr 20, 2006 at 03:54:15PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> >
> >FWIW, I've got no opinions on this patch.  The content looks fine.  My
> >only concern is that I don't much like "set" variables which succeed or
> >fail depending on the target - we can switch targets unexpectedly.
> >
> >Can we just give the error in proceed if the target can't run in
> >reverse?
> 
> You mean, "and not give an error when you say "set exec-dir"?
> 
> Well here's the thing: I've had experience with something
> very similar*, and the users complained.  They wanted to
> know sooner if there was a problem.
> 
> * Tracepoints.  You don't find out that the remote target can't
> support them until you say continue.

Sorry about the delay; I started replying to this on Thursday but
didn't finish it before I headed out for a long weekend.

I agree that, as user interface, this is unpleasant.  But here's some
of the other cases we have to consider.

(gdb) set exec-dir reverse
(gdb) target remote :1234

-> Should it work before you're connected?

(gdb) target remote :1234
(gdb) set exec-dir reverse
(gdb) disconnect
(gdb) run

-> Where do we get the error now?  We've switched targets, "run" can't
go in reverse for target child.

And as we've already seen, your error doesn't actually come at the
right time, since your remote protocol doesn't have a probe packet!
So remote will always let it succeed and child will always make it
fail, regardless of whether the remote target actually supports it.

That's mighty inconsistent.  I'm open to suggestions on a more
consistent way to present the problem.

-- 
Daniel Jacobowitz
CodeSourcery