This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: bugs in remote.c
- To: Quality Quorum <qqi at world dot std dot com>
- Subject: Re: bugs in remote.c
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Mon, 06 Dec 1999 22:24:45 +1100
- CC: gdb at sourceware dot cygnus dot com, Stan Shebs <shebs at cygnus dot com>
- Organization: Cygnus Solutions
- References: <Pine.SGI.3.95.991205140345.4355A-100000@world.std.com>
Quality Quorum wrote:
>
> Hi,
>
> 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.
(Have a read of what the protocol has to say about the query packet and
some of its its features :-)
> 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.
Remember, the existing stubs can't be described as non-compliant as,
when they were written, there was no spec to comply to :-).
I don't think it is realistic to be talking about deserting people with
less than a year old stub/gdb. If there is going to be a cleanup of the
remote protocol then a way will need to be found that doesn't disrupt
the existing user base. Per other discussions a remote-protocol v2 with
some of the existing protocol lint removed may be a solution. The
old-remote might be useful. (However, at present there is async and
extended-async while we transition the async code. I'd rather have only
one protocol variant running at a time).
enjoy,
Andrew