Re: GDB Proto: Draft revised spec...

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

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> FYI, http://www.cygnus.com/~cagney/remote-1999-06-24.html
Andrew>
Andrew> It contains all the changes recently discussed.  Editorial
Andrew> suggestions welcome.

I've been meaning to respond to this when I was on vacation the last
few days; not surprisingly, I never seemed to get around to it.

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.

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

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.


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

	NB: I tend to hate toggles, since there is no mechanism to
	determine the state of the toggle.  A new trio of commands
	"QDebug=0"; "QDebug=1"; and "qDebug" might be appropriate.  On
	the other hand, if the 'd' command has only been added to the
	i386 and m68k sample stubs, perhaps it's not been proven to be
	valuable.

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

   'D' (detach), 'k' (kill), 'r' (reset), 'RXX' (remote restart): 
        These are all related, but there is not enough information to
        distingush between them.  Also, there is no description of how
	these operate when a specific thread context has been selected
	(ie. does 'k' kill only that thread?)

   'H': How restrictive (or permissive) is the thread model.  If a
        thread is selected and stopped, are other threads allowed 
	to continue to execute?  As I mentioned above, I think the
        semantics of each command when a thread is selected must be
	described.  For example:

	'g':	If the stub supports threads and a specific thread is
		selected, returns the register block from that thread;
		otherwise returns current registers.

	'G'	If the stub supports threads and a specific thread is
		selected, sets the registers of the register block of
		that thread; otherwise sets current registers.

	etc.

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


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.

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

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

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

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

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

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

Comments?

	--jtc

-- 
J.T. Conklin
RedBack Networks