Re: bugs in remote.c

[Quality Quorum <qqi at world dot std dot com>]

On Mon, 6 Dec 1999, Stan Shebs wrote:

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

Let us give a different target name for a new thing.

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

Thanks,

Aleksey