This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: bugs in remote.c


Quality Quorum wrote:
> 
> 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 ?

Unfortunatly patches against 4.18 won't be of much use.  GDB has been
re-formatted and remote.c as had large chunks re-written.

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

It doesn't.  Burried amongst the fine print, the spec points out that
``@samp{:} can not appear as the third character in a packet''.  It
should probably go n to explain why.  If you go through all the packets,
you'll find that none of them can have a ``:'' as a third character (or
of they could GDB avoids it...).  Looking at your particular case, the
packet syntax is:

	``M'' <memaddr> , <len> :

and since <memaddr> and <len> are non empty, the shortest possible
packet is:

	X0,0:

(It is this sort of hair that prompts people to suggest a v2
protocol...)

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

Oops, sorry.  I was refering to the 20 line comment found at the top of
each stub.  That, along with a comment I deleted from remote.c, was the
original protocol spec.
The stub code in the gdb directory isn't a good reference point when
determining what is reasonable behavour.  Of hand I can think of five
different stub implementations and least one of these sends back ``OK''
when it doesn't understand a packet :-(

What is probably worth reviewing is things like threads where, there is
a clear case of all/no support.  J.T.C. also suggested that a minimum
set of required packets be identified so that it is clear what has to be
implemented.

	enjoy,
		Andrew

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]