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


> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Monday, February 25, 2013 9:33 PM

Thanks for your feedback.


> > The patch works but I'm not sure whether it is in the spirit of
> > the remote serial protocol.
> 
> I'm not sure I have a definite answer.  I'll just shoot some
> answers/questions, and let's see if we can converse on something.
> 
> Hmm:
> 
>    add_packet_config_cmd (&remote_protocol_packets[PACKET_Qbtrace],
> -       "Qbtrace", "enable-btrace", 0);
> +       "Qbtrace:bts", "enable-btrace", 0);
> 
> How would you change this when another method in addition to bts
> is added?

I would add another line, e.g.

add_packet_config_cmd (&remote_protocol_packets[PACKET_Qbtrace],
    "Qbtrace:lbr", "enable-btrace-lbr", 0);


> 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

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

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

If some GDBserver only supports the foo branch trace recording method and
neither bts nor lbr, GDB will pick foo as default and only allow foo to be configured
as recording method.

Any GDBserver that supports Qbtrace will need to support Qbtrace:off.
If necessary, I can add this to the qSupported packets or we could define
"off" as the empty recording method.


> >  @item Qbtrace
> > -The remote stub understands the @samp{Qbtrace} packet.
> > +The remote stub understands the @samp{Qbtrace} packet.  The branch
> > +trace recording method will be specified after the packet name
> > +separated by a single colon (@code{:}).  There will be one entry for
> > +each supported branch trace recording method.
> 
> How are the multiple supported methods separated?

There will be separate entries for each supported method in the qSupported
response, i.e.

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


> Hmm, I think the user reading this is left wondering what
> exactly are the supported methods.
> 
> qSupported already has a way of passing arguments:
> 
> @table @samp
> @item @var{name}=@var{value}
> The remote protocol feature @var{name} is supported, and associated
> with the specified @var{value}.  The format of @var{value} depends
> on the feature, but it must not include a semicolon.
> @item @var{name}+
> 
> So, that'd be, e.g.:
> 
>  Qbtrace=bts,foo,bar

That would be OK, as well.

How would I handle this on GDB side?
When GDB wants to enable branch tracing with method foo, what would
it send? "Qbtrace=foo"?


> An existing feature that supports multiple values is:
> 
>  @item xmlRegisters
>  This feature indicates that @value{GDBN} supports the XML target
>  description.  If the stub sees @samp{xmlRegisters=} with target
>  specific strings separated by a comma, it will report register
>  description.

Looks like xmlRegisters=... is sent by GDB.
I would need this to be sent by GDBserver and parsed by GDB.

I've also only seen this as parameter to qSupported. Is this a packet
on its own, as well?

[...]

What would be the minimal change required to fix the protocol?


Thanks,
Markus.
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052


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