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

[Michael Snyder <msnyder@redhat.com>]

Daniel Jacobowitz wrote:
> 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.

My turn to appologize.  Been implementing some of your other suggestions.

> 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?

To my present way of thinking, no.  It's target dependent,
it can't work before you set the target.  There are other
commands that won't work without a target, notably "run"
(except in the native case), or "info threads".

> (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.

Well, there you've got me.  That's a problem.

> 
> 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.

I'm stumped -- I can think of only two approaches:
1) add a probe packet, or
2) throw out the "set exec-dir" user interface (just use "rs" etc.).

I don't like to throw out the user interface without a fight,
'cause I find it a fairly intuitive interface.  So... maybe
this forces us to add a probe?