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

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 07 April 2010 02:34:12, Stan Shebs wrote:
> Here's my suggested changes, and of course it implies some target-side 
> changes as well.  Turns out that I generated some confusion for myself 
> by auto-generating tstop commands, which I realized when I was unable to 
> write a code comment that justified it. :-)
> 
> So the new behavior is that GDB always simply drops the connection.  If 
> the target can do disconnected tracing, it just keeps going.  If it 
> can't, or the query answer instructs it to not keep tracing, it stops, 
> and records the stop reason as "tdisconnection"; you'll then see that 
> when you reconnect to the target and do a tstatus.  Since tstatus 
> reports the target's state consistently now, you'll also see that in a 
> trace file.  Ditto for circularity of trace buffer.
> 
> If this behavior seems reasonable, I'll add appropriate bits to the 
> manual and repost/commit.

Thanks!  This is a good improvement, IMO.

> As for multi-process, I can see reasons to make these kinds of flags 
> either per-process or global to the target, so didn't try to guess at 
> the final decision here. :-)

The support for the feature is reported by qSupported, hence it's
certainly target-wide noawadays.  It may or not be desirable to
be able to select which processes keep tracing on disconnect, so
a per-status state flag for that also sounds acceptable --- it
could represent whether tracing will continue for a given process
after disconnection.  The flag (trace_status->disconnected_tracing)
being 0 doesn't mean the target doesn't support disconnected
tracing, so there's still no way for the common code to know it.

With the current patch, against the gdbserver that doesn't
support disconnected tracing, I still see this:

 (gdb) set disconnected-tracing on
 warning: Target does not support disconnected tracing.
 (gdb) show disconnected-tracing
 Whether tracing continues after GDB disconnects is on.

(yes, I wrote the warning, but it was a hack needed before
so that quitting wouldn't get stuck.)

With a user hat on, the "Whether tracing continues after
GDB disconnects is on." string as above looks confusing
to me.  Same, or worse for the circular-trace-buffer
setting, as that one says "target's use of", which isn't
true, it's solely GDB's intention.

Is there a way to make this pattern unconfusing?  We're
going to grow more similar options in the future, and
this will proliferate if unattended.

-- 
Pedro Alves