Re: protoc spec

[Stan Shebs <shebs at cygnus dot com>]

   Date: Thu, 16 Dec 1999 00:45:28 -0500 (EST)
   From: Quality Quorum <qqi@world.std.com>

   I have updated GDB remote  protocol specs with a few things which are 
   making it possible to do real develpment on its base. Latest spec 
   is attached to this mail, also I put it on the net:

Thanks for working on this!

My inclination for the ultimate disposition of this spec is to enhance
the protocol's description in the main GDB manual.  That is the only
GDB documentation that users (including stub developers) normally see,
and it already has a lengthy description of the protocol.  So if there
is another specification somewhere, then we'll have to spend the rest
of our lives keeping the two in sync.  One might argue that the user
manual should have a more informal description, but since it's aimed
at stub developers, who need the most accurate info, I don't see much
value in a second written description.

   1. It seems possible to fix all issues I was concerned about
      in such a way that properly developed application will 
      be backward comaptible without any additonal efforts.

      And all quirks could be covered by just three configuration 
      variables on the gdb side.

Although I generally tend to favor user-settable variables, I'm not
so keen to make users have to set them in order to keep things working
correctly.  "If it ain't broken, don't fix it."

   I am very eager to submit appropriate remote.c and I already 
   signed copyright transfer papers.

Instead of submitting an entire new remote.c, you should break changes
down into specific patches and submit each separately.

   Also, after 7 years of heavy involvment with network protocol 
   development I am kind of attached to internet-drafts and RFCs.
   Does it seem as a good idea to publish final spec as RFC ?
   It seems to me that applicaton management area of IETF
   would provide a very good review at least. At the same time 
   it introduces noticeable delays into process. So, I am not
   quite sure.

Hmmm, novel idea.  This protocol is not really an "Internet protocol",
it's more like a private protocol used by programmers during the
development process.  How large is a "noticeable delay"?  If it's
too large, then it could interfere with GDB development.

   2. Remote GDB Stub Execution Environment

   Let us start from describing environment where remote stub is executed.
   It is generally assumed that stub is executed in exception handling 
   context with all other processes in the system under debugging
   (the system) frozen until stub receives command from gdb to continue.
   Even if the stub supports per thread breakpoints, all threads of 
   execution in the system are frozen when breakpoint/exception
   is taken by any one of them

This is a little too restricted in its scope.  There are at least six
basic models of stub usage, some involving interesting combinations of
simulators and hardware boxes, and then there's the gdbserver replay
feature.  That's really why we rely on the protocol spec; as long as
the stub conforms to the spec, GDB will just assume that it's providing
a meaningful view of the actual target environment.

   Note: this specification required low case encoding. It is generally
   established practice so there are no compatibility problems here.

Why should we require lower case?

   64-bit stubs are interoperable with pre-4.19 implementations as long 
   as they do not address memory beyond  4GB. 64-bit stubs with higher
   requirements should be debugged by gdb-4.19 or newer. 

This would be making some promises that I'm not sure we're prepared
to deliver on.  For one thing, there are machines with random combos
of 32- and 64-bit features that should be handled better, most
infamously Mips.  A properly extended protocol will need to handle
this by interacting with the stub.

   3.3. Threads

   Gdb allows stub to select its own way of identifying threads. It allocates
   64-bit unsigned integers for thread representation. It worth noting, however,
   it worth noting that pre-4.19 would not properly process 64-bit 
   thread_ids >= 0x80000000. 

   Thread_id 0xffffffffffffffff should not be used, gdb reserves it for 
   ALL_THREADS thread id. This is a thread designation for all threads 
   on the remote system. It is used in cases where stub does not support
   threads or to specify command/condition applicable to all threads.

Do we have consensus on thread representation yet?  I was still thinking
about it myself...

   There is run length encoding scheme defined for ASCII encoded packets,
   it is implemented by many receivers, however, it is not used.

Let's put it in or throw it out.  This part of the spec needs to
be tightened up either way.

   Packet length is limited to 400 bytes, there are attempts to 
   allow 400 bytes of data, there are number of bugs there, so
   the safe bet is to accept 407 bytes and never send more than
   400 bytes for the whole packet. The only exception are cases 
   where stub needs more than 400 bytes to to pack all its registers. 
   Gdb has a reliable method to detect this case.

We should make a decision and make the code conform.  If stubs might
need more than 400 bytes, then 400 is not really the upper limit.
Ditto for 407.  The old rule was to use the size of registers[], on
the theory that the stub would be sure to leave enough space to return
all registers, but that's no longer satisfactory either.

   5.2. New Gdb and Old Stub

   It is highly desireable to provide interoprability between pre-4.19 
   stubs an newer gdbs. 

I would go further and say "absolutely required".  After all, if we
can go and do a new protocol, why not start from scratch?  The point
of using the existing protocol is compatibility, not innovation.

   There are few issues here to be resolved

     o  Post-4.19 gdbs are much pickier with regard to the response
	checking.  Also, many pre-4.19 stubd do not properly support 
	'kill'. 

	It seems reasonable to provide backward compatibility mode
	accounting for these differences, for example this mode could be 
	enabled by setting gdb variable 'pre419comaptible'. 

Or conversely, have a "be-picky" variable that nobody will set. :-)

     o  Some stubs developed in pre-4.19 times are not able to properly 
	respond to '!' due to documentation bug. These stubs will respond 
	'noSupport' even if they are able to support extended operations.

	It seems reasonable to cover this popular deviation with another
	settable variable, e.g. 'forceextended' .

I'll have to think about this one - it sounds wrong.

     o  Some stubs developed in per-4.19 times are not able to properly 
	support per thread debugging. 

	It seems reasonable to cover this popular deviation with another
	settable variable, e.g. 'forcenothreads'

What exactly are the older stubs unable to do?

								Stan