This is the mail archive of the gdb@sourceware.cygnus.com 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]

Re: remote nits


Quality Quorum wrote:
> 
> 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.

Its important to apreciate how GDB needs to continue to support existing
targets.  While we don't want anyone to use QL (and wish it was replaced
with something better) that doesn't mean that it is reasonable to simply
pull that code.  People in the field need to be given several years
notice and the chance to migrate to something better. it.

Much of the thread code is in this situtation.

> C. Requests Violating Protocol Principles

>    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.

You may want to study gdbserver more closely. The thing that it does is
change GDB servers behaviour.  Strictly speaking both of those should be
controlled through ``[Qq]'' packets and ``!'' should be given the boot.

>    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.

There is a good chance that nothing uses it.
However, what mechanism are you proposing that will allow GDB to
disconnect from one target programme and then connect to a second?

>    It is unclear from document that 'qRcmd' indeed allows responses
>    starting from 'E', however there is a code handling this case
>    in remote.c

The normal response to Rcmd is a HEX encoded byte-stream. E is a hex
digit.

	Andrew

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