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

[Stan Shebs <stan at codesourcery dot com>]

Pedro Alves wrote:
> 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.
>   

In a way, what the user wants to know is what qSupported reports, 
dressed up in a reasonable fashion.  Our traditional expectation has 
been the user knows already, because, well, it's the user's program and 
the user's hardware.  But as the target gets more elaborate - and 
tracepoint support is certainly a quantum jump in that direction :-) - 
that assumption breaks down.  In that vein, you may recall that one of 
our upcoming enhancements is to attach an arbitrary text string to a 
trace run, with the intended purpose of including things like a name and 
phone number, so that someone else connecting to the target can have a 
way to find out about the trace run, and know whether it's OK to mess 
with 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.
>
>   

Yeah, it's been troubling me too.  User-settable variables are GDB's 
traditional way of instructing GDB about user preferences, but the 
canned method of phrase construction is too lame to express what is 
really going on, which is "I prefer that targets to continue tracing 
after disconnect, whether or not the current target can actually do so". 
We could use something other than set/show, or invent a better method to 
produce output - there are other set/shows for which the verbiage is 
rather contorted.

Stan