This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [PATCH] Document the ThreadInfo remote protocol queries
Michael Snyder wrote:
> > An additional note on these versions of thread queries. While
> > significantly better than the ``qL'' packet these commands still have
> > problems. I'll add notes expanding on this. Briefly, however:
> >
> > o Per the query packet spec, they should be
> > prefixed with a UCASE letter if they
> > are to be official GDB packets.
> >
> > o The ``sThread..'' command assumes
> > that the GDB protocol is reliable
> > which it is not. GDB can re-issue
> > a ``sThread'' request and this can
> > lead to GDB and the target falling
> > out of sync.
>
> How about if the 'sThread' request were to be suffixed with
> the last thread ID received?
I was thinking of deprecating fThreadInfo and sThreadInfo and having gdb
try:
qThreadInfo
qThreadInfo,<sentinal>
Where sentinal could be <last-thread-id> index (counting from zero) for
next threads, or anything else.
Given ``sThreadInfo'' is in the field, we can't change it.
> > with regard to ``qfThreadExtraInfo''. As far as I know its not been
> > deployed in the field. Is there any reason to not name it correctly
> > from the start (``qThreadExtraInfo'')?
>
> Only that it conflicts with the tracepoint messages,
> which all begin with qT (see tracepoint.c).
I don't think that is a problem. The protocol requires:
@tab @code{q}@var{query}
@tab
Request info about @var{query}. In general @value{GDBN} @var{query}'s
have a leading upper case letter. Custom vendor queries should use a
company prefix (in lower case) ex: @samp{qfsf.var}. @var{query} may
optionally be followed by a @samp{,} or @samp{;} separated list. Stubs
must ensure that they match the full @var{query} name.
The last sentence is ment to ensure that the target's query handling
code matches using something like:
strcmp (packet, "qThreadInfo")
instead of
packet[0] == 'q' && packet[1] == 'T' && packet[7] == 'I'
Should ``C'' also be suceeded by something like ``qThread''? Is ``C''
still used?
Andrew