This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: bugs in remote.c
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: bugs in remote.c
- From: Quality Quorum <qqi at world dot std dot com>
- Date: Sat, 4 Dec 1999 07:27:01 -0500 (EST)
- cc: gdb at sourceware dot cygnus dot com, Stan Shebs <shebs at cygnus 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