This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tracing broken if target doesn't do disconnected tracing


Pedro Alves wrote:
On Wednesday 07 April 2010 23:04:38, Stan Shebs wrote:
Pedro Alves wrote:

I suggest we change that to simply:

  /* If running interactively, warn the user a trace run is ongoing.
     She may want to cancel detaching instead.  */
    if (current_trace_status ()->running && from_tty)
      {
        if (current_trace_status ()->disconnected_tracing)
          {
            if (!query (_("Trace is running and will continue after detach; detach anyway? ")))
              error (_("Not confirmed."));
          }
        else
          {
            if (!query (_("Trace is running but will stop on detach; detach anyway? ")))
             error (_("Not confirmed."));
          }
      }

- simpler, more coherent, less explaining, less confusing.
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?


I'd say that this use case would be much more common, and if
gdb gave you the option of turning disconnected tracing _on_
would be more helpful than the other way around (having trace
running and wanting it to stop on detach). After having used
tracing for a while (granted, not really in the field), I believe
that this "do you want to stop tracing" query will get old soon. But,
I can see that I can't manage to convince you of anything, so
please, let's not get stuck on this issue, and let's move forward
with whatever you think is right.

My mental model is that users will tend to have disconnected tracing on by default if possible, because it ensures that the tracing run isn't prematurely terminated by GDB crash or loss of network connection. But yeah, without much user feedback yet, we are just speculating on what users will prefer. So I'll check in my version, and if people complain about it, then you'll get that delicious feeling of vindication. :-)


Stan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]