Re: GDB Proto: Draft revised spec...

[jtc@redback.com (J.T. Conklin)]

>> 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 :-(

It's a bit of a stretch, especially since we haven't resolved the
issues regarding processor varients yet.  

Note the WDB protocol (used by vxWorks) specification also leaves
details such as which registers are in each reg set, and the offsets
of registers within a set are left unspecified.  So, if the RDP spec
ends up omitting similar details, it won't be the only one.

I suspect that we won't be able to have the "ideal" spec.  But thats
not to say we shouldn't nail down everything that can be nailed down.

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

Don't feel obligated on my account.  My only encounter with 'd' was
removing all of the printf()'s from i386-stub.c when I integrated it
into Cisco's PIX.  I have never used it myself, and am unsure of its
real value.  When debugging a stub, the user can add target specific
output related to the particular areas that are malfunctioning. IMO,
such an approach is more likely to be successful than any set of pre-
defined output such as what's present in i386-stub.c or m68k-stub.c.

However if there is a need, I think it should be stated that the 'd'
(or QDebug) commands are not intended to be used to control an
application's own internal diagnostics or logging facilities.  That
would muddle the line between application and exception handler.

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

No doubt it's botched, but I'm not sure we need to wait until GDBs
event model is updated.  

Most of the stubs distributed with GDB convert exceptions to signal
numbers using constants cooresponding to the signal numbers used on
some host system.  Although there's no guarantee that those numbers
will be same on the target, common ones seem to be.  We could assert
that a 4 from the target should be mapped to the hosts SIGILL, a 5
mapped to SIGTRAP, etc.

On the other hand, leaving things as they are gives the user the
flexibility to map exceptions to unique signals (for example,
i386-stub.c maps several exceptions to signal 11)

>> * 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?

Thanks for the gdbserver reference.  I didn't know anything that used
extended remote before.  

It appears that GDB, gdbserver and the extended remote debug protocol
(ERDP?) are attempting to create an debug environment that resembles
native host debugging as close as possible.  This seems to be a good
idea.  However, the implementation seems to have a lot to be desired.

In gdbserver, extended_remote changes the semantics of program exit.
Instead of exiting, gdbserver restarts the the program so that there
is always a program to be debugged.  As a result, there is no way to
cleanly exit a session.

I've only thought of this for a moment while writing this reply, but
an alternative would be that all of the commands that manipulate the
state of the program (g/G, p/P, c, s, ...) would return an error if
there was no program being debugged.  The 'R' (run/restart) command
would create a new program context.  remote_open() would be changed to
always call 'R'.  I think this scheme even more closely matches native
debugging.

>> * 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?

With an gdbserver like the above, an argument command might even be
useful.  It doesn't solve the problem with the size of the argument
list being limited by PBUFSIZ though.

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

If it works, the clutter is justified.

	--jtc
-- 
J.T. Conklin
RedBack Networks