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: [rfc] remote, btrace: add branch tracing protocol to Qbtrace packet


On Tue, 26 Feb 2013 10:24:32 +0100, Metzger, Markus T wrote:
> > What if a remote stub sends in "Qbtrace:foo", but no mention of
> > bts?  The remote understands "Qbtrace:off", but this does not
> > express that.
> 
> At the moment, GDB and GDBserver equate btrace with btrace-bts.
> 
> Eventually, I want GDB to collect all the supported btrace methods and allow
> the user to specify one of the supported methods, i.e.
> 
> set record btrace method bts
> set record btrace method lbr

>From the user interface point of view I expected rather:
	record full
	record btrace
	record lbr

It is already one level of "configuration", two levels of configuration make
it a bit too complicated for the user IMO.  Sure the code inside GDB would be
shared between "record-btrace" and "record-lbr" targets but that is hidden
from the user.


> I would create the respective sub-commands dynamically after querying the
> target.  Unfortunately, we cannot remove the commands again on disconnect.

I do not think there should be dynamically created commands, it is not
established in GDB.


> As default, GDB will pick one of the supported methods, say, the first in the
> qSupported response.

Do you expect more "btrace" variants than "bts" and "lbr"?

If "lbr" exists it should be enabled by default without asking the user.

For "bts" one has to type "record btrace" as it is a noticeable slowdown.

Or do I miss some plans?


> There will be separate entries for each supported method in the qSupported
> response, i.e.
> 
> ...:Qbtrace:bts+:Qbtrace:lbr+:...

colons vs. semicolons mistaken:

  ...;Qbtrace:bts+;Qbtrace:lbr+;...


No preference for the qSupported details, I am OK with your proposal myself,
"qXfer" gdbserver->gdb feature is designed that way already.


Thanks,
Jan


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