This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Reverse debugging, part 3/3: user interface / docs
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?