Re: bugs in remote.c

[Andrew Cagney <ac131313 at cygnus dot com>]

Quality Quorum wrote:
> 
> Hi,
> 
> I found a few minor bugs in remote.c (gdb-19990519), I can provide
> fixes if necessary.

Patches are always useful (got the GPL assignment in place? :-).

I've also got some questions.  I'm lost by some of the points.

> 1. remote_write_bytes - either ':' has to be escaped too or
>    sequences have to be outlawed once and forever.

I'm confused.  Can you explain exactly what the problem is?

> 2. set_thread - ignores returned packet.
> 
> 3. remote_get_threadinfo and remote_get_threadlist - assume that first
>    two chars of the packet are fine - this one can really screw things up.

Outch! Yes.

The target can make GDB read uninitialized memory from the top-of-stack
:-(.  Could you please submit a patch for this?

Stan, you may want to keep an eye out for this sort of thing.


> 4. remote_open_1 - does not check for returned errors or non-supported
>    extended ops.

In the case of the extended op, it isn't possible to verify the
response.  See the protocol specification for details of the problem.

> 5. Inconsitent processing of returned errors:
>        a. Error is ignored by set_thread, remote_thread_alive,
>           remote_get_threadinfo, remote_get_threadlist,
>           remote_current_thread, extended_remote_restart,
>           remote_open_1, remote_fetch_registers, check_binary_download,
>           remote_query.

Can you expand on these  I'm unclear as to which errors you're refering
to and what processing should be present.  If you've a patch I'd be very
interested.

> 6. Inconsistent processing of returned no-support status:
>        a. compare_sections_command - consideres no support for the
>           operation a fatal error.
> 
>        b. It is ignored by set_thread,  remote_thread_alive,
>           remote_open_1, remote_write_bytes, remote_read_bytes,
>           remote_store_registers, remote_fecth_registers.
>           Naturally, some of these cases are improbable, however, 
>           it does not mean that it shold not be checked to flag
>           faulty stubs.
> 

One note of caution. GDB is generally slack when it comes to verifying
responses.  This is because the original spec (have a look in any
*-stub.c file) didn't define these and where defined most
implementations ignored them. The general approach has been to verify
just sufficient to be fairly sure that the target is still ok.

	enjoy,
		Andrew