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:
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


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