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

[Pedro Alves <pedro at codesourcery dot com>]

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.

-- 
Pedro Alves