Re: bugs in remote.c

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

On Sat, 4 Dec 1999, Andrew Cagney wrote:

> 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 will do it shortly, is it OK to do it against 4.18 ?

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

Let us suppose you got a packet  "$Xab:cd....", does it
contain sequence or not ?

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

Once you got "$E..." it is either memory access error (which is 
processed properly in my view) or an indication of something 
truly bad which is fatal in my view.

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

I looked through the stubs and it seems to me every stab does a pretty 
good job of returning "$#00" on anything it does not understands. 
IMHO, there is no point in ignoring no-support status. I will submit
patch which will clarify the issue.

> 
> 	enjoy,
> 		Andrew
> 

Thanks,

Aleksey