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




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



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