This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
remote nits
- To: gdb at sourceware dot cygnus dot com
- Subject: remote nits
- From: Quality Quorum <qqi at world dot std dot com>
- Date: Sat, 11 Dec 1999 14:44:44 -0500 (EST)
Hi,
I found more remote nits reading manual on the net and
gdb-19990913/gdb/remote.c . Below is summary.
A. Handling of Depreciated Elements
It seems to me that debugger should never emit
depreciated requests. 'qL' request is marked
as depreciated in the document, however, there is
code which will emit it.
B. Three Ways of Specifying a Thread.
There are THREE ways of specifying thread: signed 32-bit
integer (used by 'H' request and 'T' response), 16-bit unsigned
integer (used by 'T' request and 'QC' response) and 8-byte thread
id (used by 'qL' and 'qP' requests and corresponding responses).
BTW, Code implementing 'QC' responses will handle 32-bit signed
integers properly while manual tells us that it is using 16-bit
unsigned ones.
It seems to me that only one way should survive and others
should die. My list of preferences is (1) 32-bit integer,
(2) 8-byte thread ref, (3) 16-bit unsigned integer. (*)
C. Requests Violating Protocol Principles
There are four commands which violate protocol
principles. '!' is expecting empty response both
in case it is supported or not. If stub does not support
'D' it will loop forever trying to tell gdb about it.
'qRcmd' can have a valid request starting from 'E'
'TXX' request interprets 'ENN' as thread dead indication.
It seems to me that '!' is not that bad. At least one
popular implementation I saw (gdbserver) will report last status
in response to '!'. It seems that a low pain way to deal
with it is to have local variable, say 'remoteforceextended'.
If this variable is set then any response to '!' is considered
a success, otherwise "" means no support, "OK" or status string
mean support, everything else considered an error.
It seems to me that 'D' could be depreciated: we can use 'c'
followed by connection close instead - 'c' supposed to have exactly
same effect and is required to be implemented. Another way is
to define new detach request which will require stub to send
reply before disconnecting.
It is unclear from document that 'qRcmd' indeed allows responses
starting from 'E', however there is a code handling this case
in remote.c
It seems to me that it is possible to leave TXX request as is.
Moreover it seems like it is going to be depreciated as a part
of thread id normalization process anyway.
D. Bugs
Three reqests will not work with 64-bit targets 't', 'qCRC' and
'qOffsets' due to address range limitations.
I feel ready to write (a) a formal description of the protocol
with (b) proposed changes, once issue (*) of proper representation of
thread ids is resolved one way or another.
Thanks,
Aleksey