This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: bugs in remote.c



   Date: Sun, 5 Dec 1999 14:17:31 -0500 (EST)
   From: Quality Quorum <qqi@world.std.com>

   It seems to me that minimal requirements to a stub should be:

   1. Return empty on everything it does not understand.
   2. Does not change its mind about understanding something while
      in the middle of operation. E.g. if it supports extended ops 
      should also support restart.
   3. Return 'ENN' if (a) fatal error occured or (b) memory error 
      occured.

   It seems to me that it is an absolute minimum set of requirements,
   which will allow to complex stuff like queries to work properly.

In general, that is what we've always expected from stubs.  The
"empty response to unsupported packet" rule, for instance, has been
written down for a long time.

   It seems to me that people with uncompliant stubs should keep
   using gdb-4.18 or earlier, which are pretty decent debuggers
   anyway. Also, it seems like really simple thing to add 
   something like 'old-remote' target which will lack new and shining
   stuff (e.g. extended ops, single register assignments and queries) but
   will be more tolerant towards old screwed up stubs.

There are a *lot* of stubs in ROM and out in the field; so I'd be very
reluctant to decree that they are no longer to be supported, even by
using a different target name.  Instead, we should continue to tighten
up the new standard, but allow exceptions if truly necessary, on a
case-by-case basis.  For instance, a couple letters can never be used
for packet type because somebody already used them.  That's OK, we
have lots more letters available to us, and they're now explicitly
stated as being reserved for future use.

Actually, it would be interesting to find out about the lowest (sea
floor?) and highest uses of GDB stubs (Mars?), smallest computer, most
hostile environment, etc.  Who's got the best story?

								Stan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]