On Thursday 08 April 2010 19:18:40, Stan Shebs wrote:
The downside of this design is that if you did want to shut tracing
down, you have to cancel the detach, do a tstop, then redo the detach.
It's not crucial perhaps, but it seems a bit pedantic for GDB to have
the power to choose whether to keep the trace running, but not to
exercise it, and to insist that you have cancel and type the command
yourself. Perhaps the crux of the confusion is that this is really a
three-way choice - trace/detach, tstop/detach, cancel - and a pair of
yes/no questions is not a good way to model it.
That's just begging for:
The downside of your current design is that if you did want to detach
and leave tracing running, you have to cancel the detach, do a "set
disconnected-tracing on", then redo the detach.
It's not crucial perhaps, but it seems a bit pedantic for GDB to have
the power to choose whether to keep the trace running, but not to
exercise it, and to insist that you have cancel and type the command
yourself.
:-)
Um, I must be missing the joke, it looks like you cut-n-pasted verbatim?
Your patch only asks the user whether she wants to leave tracing on or
stop it when "set disconnected-tracing" was on. If it was "off" (the
user forgot to set it on, as it is off by default), you still have to
cancel the detach and issue a "set disconnected-tracing on" command.
The joke was that your words only justify one of the branches in your code,
and can be used to justify my point in the other branch. Compare the
first sentences. As is, your patch doesn't expose GDB's power to
turn disconnected-tracing _on_, only _off_. Following your mental model,
a user would be much more thankful if gdb offered the ability to turn
it on, on the spot.