remote nits

[Quality Quorum <qqi at world dot std dot com>]

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