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

[Stan Shebs <stan@codesourcery.com>]

Pedro Alves wrote:
> The gdbserver tracepoints patch I just posted doesn't
> include disconnected tracing yet.  Note what
> happens then: [...]
>   
>  
>
> This is because common code outside remote.c has no clue
> whether the target supports or not disconnected tracing, and
> just assumes it does.  Exposing that property seems to
> conflict a bit with the desire to allow
> "set disconnected-tracing on" before actually being connected,
> so, I've avoided doing it so far.  Maybe we could get away with
> a tristate "yes|no|not-known-yet-maybe".
>
> WDYT?  Shall I proceed with this as is?  Would you like to
> address this?
>   

This is pretty close to what we want, I think; but generic code does 
need to know about this, so that disconnect_or_stop_tracing can say the 
right things.  For instance, a target that cannot do disconnected 
tracing should warn that the user that the detach is about to bring an 
ongoing trace experiment to a halt, and certainly shouldn't tease the 
user with a query() that can't possibly succeed.

I'm thinking that this is in some ways like the circular trace buffer 
flag, and could be reasonably made accessible via the trace_status 
structure.  Unless you're just dying to do this yourself :-) , I'll take 
care of the two together.

(I can see where this is going longterm - struct trace_status is 
effectively a host-side copy of the agent's state, echoed back in 
response to any instructions that GDB sends down.)

Stan