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] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |