Re: PATCH to buildsym.c

[Stan Shebs <shebs@cygnus.com>]

   From: Jim Blandy <jimb@cygnus.com>
   Date: 03 Dec 1999 12:08:13 -0500

   I'm sympathetic to the concerns about possibly breaking other systems,
   but I don't think it's good to put off changes with known benefits
   just because we're not sure whether it might break something, though
   we're not sure what.  It's sort of paralyzing to approach things that
   way.

Generally you want to adjust your risk-taking to the situation.  A
speedup in platform-specific code is almost always safe, a change in
the compiler/debugger interface has more serious consequences.  It's
been a while now, so most people have probably forgotten, but when we
changed some stab values to be assumed to be function-relative rather
than absolute, it took two years for all the aftereffects to settle
out - there were far more stabs readers in the world than we realized!

   I think we should make the change, and comment the code with an
   explanation of why it should be this way.  If it does break something
   else, at least we can make a decision in the presence of data.

Sure, I can go along with that.

   In any case, as the symtab maintainer, I think the change is okay.
   When Stan turns out to be right, and the next Mars Lander mission
   fails because they can't set a breakpoint where they need to, I'll
   throw myself on my sword, okay?

:-) Boy, how must it feel to know your mistake resulted in the loss
of a billion-dollar space probe - death might seem preferable to going
back in to work the next day...

								Stan
From jimb@cygnus.com Fri Dec 03 14:38:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: 64-bit stabs?
Date: Fri, 03 Dec 1999 14:38:00 -0000
Message-id: <npso1j8xbi.fsf@zwingli.cygnus.com>
X-SW-Source: 1999-q4/msg00441.html
Content-length: 118

Have we ever used STABS in 64-bit executables before?  How large is
the value field of a stab in a 64-bit executable?
From ac131313@cygnus.com Fri Dec 03 23:10:00 1999
From: Andrew Cagney <ac131313@cygnus.com>
To: Quality Quorum <qqi@world.std.com>
Cc: gdb@sourceware.cygnus.com, Stan Shebs <shebs@cygnus.com>
Subject: Re: bugs in remote.c
Date: Fri, 03 Dec 1999 23:10:00 -0000
Message-id: <3848BE1F.DA83579B@cygnus.com>
References: <Pine.SGI.3.95.991201173338.27503A-100000@world.std.com>
X-SW-Source: 1999-q4/msg00442.html
Content-length: 2415

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
From qqi@world.std.com Sat Dec 04 04:27:00 1999
From: Quality Quorum <qqi@world.std.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: gdb@sourceware.cygnus.com, Stan Shebs <shebs@cygnus.com>
Subject: Re: bugs in remote.c
Date: Sat, 04 Dec 1999 04:27:00 -0000
Message-id: <Pine.SGI.3.95.991204071415.15045A-100000@world.std.com>
References: <3848BE1F.DA83579B@cygnus.com>
X-SW-Source: 1999-q4/msg00443.html
Content-length: 2501

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