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 Thu, 28 Feb 2013 09:45:23 +0100, Metzger, Markus T wrote:
> Btw, I think target sub-commands are created dynamically when you call add_target.

Yes; but add_target is called unconditionally during GDB startup so from the
user point of view the commands are not created dynamically.


> > If "lbr" exists it should be enabled by default without asking the user.
> 
> We could do that until the user requests BTS tracing or full tracing. This would
> mean that there would be a record target pushed implicitly. With the current
> logic, this would prevent displaced stepping and would require an explicit
> record stop before another record target can be pushed.
> 
> I think we should discuss the details once we start sending patches to enable
> LBR tracing.

Yes; I understand it may not be trivial but LBR by default would be great.


> > No preference for the qSupported details, I am OK with your proposal myself,
> > "qXfer" gdbserver->gdb feature is designed that way already.
> 
> Pedro objected and rather wanted a comma-separated list, i.e.
> 
> ....;Qbtrace=bts,lbr;...
> 
> I'm fine either way. For the way I proposed and what seems to be your preference,
> as well, I already found code in GDB to handle it. For Pedro's preferred way, I have
> not found anything that I could reuse.
> 
> I would like to get the minimal changes in with the btrace series so we don't need
> to rework the protocol later on and are forced to maintain backwards compatibility.
> I do not intend to implement full support for different branch trace recording
> methods right now, since we currently only have one. We will add that support
> when there's a need.
> 
> Pedro did not respond to my reply. I don't know how to proceed, here.

OK; hopefully Pedro will.  For example qXfer:* sets a precedent for it IMO
although delegating all gdbserver decisions to Pedro:

PacketSize=3fff;QPassSignals+;qXfer:libraries-svr4:read+;qXfer:auxv:read+;qXfer:spu:read+;qXfer:spu:write+;qXfer:siginfo:read+;qXfer:siginfo:write+;qXfer:features:read+;QStartNoAckMode+;qXfer:osdata:read+;multiprocess+;QNonStop+;QDisableRandomization+;qXfer:threads:read+;ConditionalTracepoints+;TraceStateVariables+;TracepointSource+;DisconnectedTracing+;FastTracepoints+;StaticTracepoints+;InstallInTrace+;qXfer:statictrace:read+;qXfer:traceframe-info:read+;EnableDisableTracepoints+;tracenz+


Thanks,
Jan


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