This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: remote nits
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: remote nits
- From: Quality Quorum <qqi at world dot std dot com>
- Date: Tue, 14 Dec 1999 09:47:42 -0500 (EST)
- cc: gdb at sourceware dot cygnus dot com
On Tue, 14 Dec 1999, Andrew Cagney wrote:
> 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.
I do appreciate and I do understand it, however, there is also a need
in clear documentation. It seems to me that we have to use
different term (which one ???) to describe things which are going
to be replaced, however, are still in use.
BTW, my general attitude is 'do not change anything, unless it is
absolutely necessary', however, clean documentation, with clear
migration part is essential in my view.
>
> Much of the thread code is in this situtation.
>
There is much more to the thread code than that. As far as I can
see it looks as follows, (1)gdb uses 32-bit signed pid internally
to identify thread, (2) remote machine uses the 64-bit address of the
thread control block to identify the thread,(3)gdb side does
conversion, (4) this conversion is not fully/cleanly implemented
yet.
There are three ways to address this issue:
1. Make target to convert its internal thread_ids into pids.
Pro: (a)it provides nice abstract interface, (b) it is not that
big a deal for a target to implement, (b) it allows for effective
implementation of thread list feature, (c) it is fully
compatible with all operations except 'qL' and 'qP' requests .
Con: (a) it breaks 'qL' and 'qP' requests. (In my view this is
a fatal problem for this approach).
2. Fully implement conversion on gdb side.
Pro: (a) it provides thread_id which may have meaning for the person
debugging the stuff, (b) it is trivial to implement on
gdb side, (c) it does not break 'qL' and 'qP' requests.
Con: (a) there are cases where it will break 'qC', 'T' - both cases
and 'Hx' requests, (b) in many cases target side overhead
similar to the case (1) will be required to properly implement
thread list.
3. Fully implement conversion on gdb side with modifications:
o Thread ids visible on the wire are 64-bit unsigned values
o Thread id 0xffffffffffffffff means 'all-threads', if no
threads are implemented this is the only thread visible
to gbd (internally it matches to magic - 'all-thread' pid of
4200).
o There are two formats to represent a thread_id on the wire.
V-thread - byte encoded into 1-16 characters MSB first,
with possibly omitted leading 0's, with 'all-threads' id
encoded as '-xxxxxxxxxxx', where 'xxxxxxx' is any combination of
1-16 hex digits, with preferred form being '-1'. E.g.
if(thread_id == XXX_VAL_THEADID_ALLTHREADS)
{
out_buf[0] = '-';
out_buf[1] = '1';
out_buf[2] = 0;
}
else
{
sprintf(out_buf, "%Lx", thread_id);
}
and
F-thread - byte encoded into 16 characters MSB first,
e.g. sprintf(out_buf, "%016Lx", thread_id);.
o Requests 'Hx', 'T' and 'qC' use V-thread format, 'qP' and 'qL'
use F-thread format.
Comparing to (2) it has additional advantages (a) of being
completely compatible with all existing implementations,
while providing a clean migration path, (b) it will allow to
use 'qL' and 'qP' requests without reinventing them.
In my view (3) is a clear winner I am going to write formal document
specifying protocol using this encoding during the day today.
> > 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 we have widely used implementation (gdbserver)
with sensible handling of '!', so in my view it is safe to make it
default behavior with old behavior supported when some variable (e.g.
extendedremoteforce) is set.
> > 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?
1. If there is no threads supported on the remote machine, then
the topic is moot.
2. It there threads then the sequence could be
'Hc...' - set new control thread
'Hg...' - set new generic thread (whatever does it mean).
'xxxx' - set break point in the new control thread context
'c' - continue
> > 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.
???????? As far as I understand the document normal response to
Rcmd is a sequence of zero of more 'O' packets followed, by OK or 'ENN'.
IMHO, the only use of Rcmd is to allow user to type some command
and see the response, in all other cases query should be defined and
used not a command, we have raw queries just for this purpose.
>
> Andrew
>
Thanks,
Aleksey