Re: GDB Proto: Draft revised spec...

[Andrew Cagney <ac131313@cygnus.com>]

"J.T. Conklin" wrote:
> 
> I think the changes are a big improvement, but IMO there is still a
> non-trivial amount of work necessary in order make it the "official"
> remote debug protocol specification.  My most significant complaints
> are a lack of distinction between the remote debug protocol and the
> protocol as implemented by GDB and the sample stubs.  Ideally, the
> specification should not have to mention GDB (or the stubs) at all.

Ideally yes, unfortunatly the contents of packets such as g/G are
defined by what is in GDB :-(

> Another problem is that the specification is incomplete.  In most
> cases, commands (and their interactions) are simply underspecified;
> but in some it completely defers the definition to a specific stub
> for a command (ie. the reset command).

Yes, it's been suggested that I should go over each packet and clearly
identify behavour such as not implemented, success and fail responses.

> I believe either you or Stan mentioned a remote debug protocol
> ``RFC'', perhaps tongue-in-cheek, yet I think that level of detail is
> precisely what is needed.  Although both GDB and the sample stubs are
> available for study, one should be able to write a functional stub
> from the specification alone.

Probably Stan.

> Not wanting to simply whine, here are some specific suggestions:
> 
>    'd': Instead of refering to i386-stub.c and m68k-stub.c, expand
>         the description.  Perhaps something like "Toggle flag used to
>         control implementation specific debug output".

I'll both deprecate the packet and add a note recommendation that
``QDebug=N'' and ``QDebug.xxx=N'' be used.

>    'C' and 'S' (also the 'T' and 'S' responses to all execution
>         commands): There needs to be a definition of what the values
>         are.  At present, the host signal values are assumed to be the
>         same ones used by the target.  This doesn't matter to many
>         folks, since they only use one type of host.  But there is a
>         potential for major lossage.

The signal coding was botched.  It is so unix centric that it is
dangerous.  However, to fix it a re-think of GDB's internal signal/event
model would be needed.

>    'm' and 'M': Should probably mention that there is no alignment or
>         width guarantees on either side.  GDB cannot assume a word
>         sized read/write command will be performed with word sized
>         access; likewise the stub cannot assume a word sized command
>         will be word aligned, etc, etc, etc.

Ah, yes, that problem :-(

> Other misc stuff:
>     * Need description of general argument and response encoding:
>       addresses, memory, and registers.  This may un-clutter some
>       of the individual command descriptions.

Good idea.

>     * Need a description of the extended remote protocol.  I've been
>       using the RDP for a long time, and I am still not sure exactly
>       what the extended protocol brings to the table.  The document
>       only states the 'RXX' command supported, but does not describe
>       what 'RXX' does.

I'm actually strugglying to find anything unique about that protocol. 
Apparently it was added for gdbserver which does use it.  Anyone know
any more about the history of that extension?

>     * The 'A' command seems out of place.  Program arguments are an
>       awfully high level concept for a low level protocol.

FYI, I found it in a stub.  I'll decprecate it.  Looks like something
else that GDB never used?

>     * Listing all the characters reserved for future commands
>       individually results in a cluttered look.  Perhaps they could be
>       listed in a paragraph following the table.  Or maybe listed
>       implicitly with a statement like "All other letters are reserved
>       for future use".

I'd prefer to have the un-used characters ``in your face''.  Since the
previous arangement lead to a plitera of un-documented letters, I'm
hopeing that explicitly documenting each as reserved might act as a
deterrent.

What I will do is contract the exequences of reserved letters.

>     * Several commands contain the comment "Not supported by all
>       stubs", but that is true of most.  Perhaps the commands that are
>       required should be indicated instead (g/G, m/M, c, ? --- is that
>       all?)

I'll look at this.

>     * binary write commands escape $, #, and 0x7d characters, but this
>       is not described.

Ah!

>     * is the checksum signed or unsigned?  Is it seven or eight bits?
>       (most stubs chop the most significant bit of each char in their
>       getpkt routine).  This only effects the binary write command.

Good question.

The section should probably also mention the ``maintainer packet''
command.

	thanks,
		Andrew