Re: remote nits

Re: remote nits

[Andrew Cagney]

Quality Quorum wrote:
> 
> On Wed, 15 Dec 1999, Andrew Cagney wrote:
> 
> > Quality Quorum wrote:
> > >
> > >
> > > ???????? 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'.
> >
> > One of the specified return codes is:
> >
> >     reply OUTPUT
> >       A command response with the hex encoded output string OUTPUT.
> 
> This one should be outlawed before it is too late, it simply does not
> make any sense.

Sorry, to late.  Technically it is the ``OOUTPUT'' bit that shouldn't be
there.  Only the qRcmd packet supports it.  However, I do see your
point.

	Andrew
From toy@rtp.ericsson.se Tue Dec 14 15:29:00 1999
From: Raymond Toy <toy@rtp.ericsson.se>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Sparc V9 disassembly?
Date: Tue, 14 Dec 1999 15:29:00 -0000
Message-id: <14422.53941.521702.962384@rtp.ericsson.se>
References: <14421.15563.476881.755513@rtp.ericsson.se> <3855DB8F.8EC29AB3@cygnus.com>
X-SW-Source: 1999-q4/msg00509.html
Content-length: 1009

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

    >> 
    >> info archi
    >> set archi sparc:v9a
    >> disassemble <addr1> <addr2>
    >> 
    >> It seems the bug is in gdb_print_insn_sparc.  It sets info->mach to
    >> TM_PRINT_INSN_MACH, which is the sparc/sparclite.  If I use gdb to
    >> change this to 8 (sparc v9?), the disassembler recognizes the v9
    >> instructions.
    >> 
    >> Is this correct behavior?

    Andrew> I'd try it with the current GDB however, I suspect that SPARC GDB
    Andrew> currently ignores requests to change the architecture via ``set
    Andrew> architecture''.

I commented out the offending line in gdb_print_insn_sparc, and
recompiled.  Everything seems to work according to the way I want, so
set architecture does work.  A peek at the code seems to indicate that
as well.

I will, however, try the most recent snapshot.

Since the code has made a conscious effort to set info->mach, I wasn't
really sure if everything else would work.

Ray

Re: remote nits

[Quality Quorum]

On Wed, 15 Dec 1999, Andrew Cagney wrote:

> Quality Quorum wrote:
> > 
> > On Wed, 15 Dec 1999, Andrew Cagney wrote:
> > 
> > > Quality Quorum wrote:
> > > >
> > > >
> > > > ???????? 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'.
> > >
> > > One of the specified return codes is:
> > >
> > >     reply OUTPUT
> > >       A command response with the hex encoded output string OUTPUT.
> > 
> > This one should be outlawed before it is too late, it simply does not
> > make any sense.
> 
> Sorry, to late.

Then it has to be depreciated right away - it is broken in too many
places and it is not going to ever work correctly anyway.

And again we can cover it be variable, say - 'brokenqrcmd' 

> Technically it is the ``OOUTPUT'' bit that shouldn't be
> there.  Only the qRcmd packet supports it.  However, I do see your
> point.
> 
> 	Andrew
> 

Thanks,

Aleksey

Re: remote nits

[Quality Quorum]

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

Re: remote nits

[Andrew Cagney]

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

One of the specified return codes is:

    reply OUTPUT 
	A command response with the hex encoded output string OUTPUT. 

and is separate to in intermediate O packet.

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

Sorry you've lost me here.

	Andrew
From qqi@world.std.com Tue Dec 14 08:09:00 1999
From: Quality Quorum <qqi@world.std.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: remote nits
Date: Tue, 14 Dec 1999 08:09:00 -0000
Message-id: <Pine.SGI.3.95.991214105557.17037A-100000@world.std.com>
References: <38566371.ECAB7FA7@cygnus.com>
X-SW-Source: 1999-q4/msg00504.html
Content-length: 1043

On Wed, 15 Dec 1999, Andrew Cagney wrote:

> Quality Quorum wrote:
> > 
> > 
> > ???????? 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'.
> 
> One of the specified return codes is:
> 
>     reply OUTPUT 
> 	A command response with the hex encoded output string OUTPUT. 

This one should be outlawed before it is too late, it simply does not
make any sense.

> > and is separate to in intermediate O packet.


> > > 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.
> 
> Sorry you've lost me here.


The question is who is going to issue a command and to interpret a command
response ? 

If it is a user then proper response have to be in user-readable
form ('O' packet). If it is machine, then command query should not be
used (we have raw queries for the purpose).

> 
> 	Andrew
> 

Thanks,

Aleksey

Re: remote nits

[Quality Quorum]

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

It seems like there is an established practice of using low case
characters for hex encodings sent by stubs - otherwise 'm' request
would never work correctly. So, this is not an issue at all, unless,
you would tell me that existing implementations of qRcmd break
this one too :).

BTW, I got it while working on v0.2 of protocol spec, I was quite 
surprised that the positive impact of this exercise was that immediate.
 
> 
> 	Andrew
> 

Thanks,

Aleksey