Re: PATCH to buildsym.c

[Todd Whitesel <toddpw@windriver.com>]

> hard for me to imagine compiler people intentionally emitting a line
> note correponding to the next instruction, then emitting another line
> note *not* corresponding to that instruction, and then emitting the
> instruction itself.  That's a little odd.

Compiler people vary widely in their committment to good debug info output.

I'll spare you the details, but over the years I've learned to be very
cynical about this. Attribute preservation in the face of optimization is
actually a quite tough problem, whether it's for debug info or volatile
qualifiers or something else. Many compiler folks I have dealt with just
seem to stick their heads in the sand and wish the whole issue would simply
evaporate, but of course it can't.

Having worked on compilers a bit myself, I've seen how the preservation
code can explode the complexity of many algorithms. It may be hard, but
it's still necessary. I consider this to be more of a "grand challenge"
problem worthy of study than the futile ILP stuff dictated by Merced.

-- 
Todd Whitesel
toddpw @ windriver.com
From qqi@world.std.com Mon Dec 06 16:54:00 1999
From: Quality Quorum <qqi@world.std.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: bugs in remote.c
Date: Mon, 06 Dec 1999 16:54:00 -0000
Message-id: <Pine.SGI.3.95.991206195415.3408A-100000@world.std.com>
References: <199912062200.OAA24749@andros.cygnus.com>
X-SW-Source: 1999-q4/msg00461.html
Content-length: 2089

On Mon, 6 Dec 1999, Stan Shebs wrote:

> 
>    Date: Sun, 5 Dec 1999 14:17:31 -0500 (EST)
>    From: Quality Quorum <qqi@world.std.com>
> 
>    It seems to me that minimal requirements to a stub should be:
> 
>    1. Return empty on everything it does not understand.
>    2. Does not change its mind about understanding something while
>       in the middle of operation. E.g. if it supports extended ops 
>       should also support restart.
>    3. Return 'ENN' if (a) fatal error occured or (b) memory error 
>       occured.
> 
>    It seems to me that it is an absolute minimum set of requirements,
>    which will allow to complex stuff like queries to work properly.
> 
> In general, that is what we've always expected from stubs.  The
> "empty response to unsupported packet" rule, for instance, has been
> written down for a long time.
> 
>    It seems to me that people with uncompliant stubs should keep
>    using gdb-4.18 or earlier, which are pretty decent debuggers
>    anyway. Also, it seems like really simple thing to add 
>    something like 'old-remote' target which will lack new and shining
>    stuff (e.g. extended ops, single register assignments and queries) but
>    will be more tolerant towards old screwed up stubs.
> 
> There are a *lot* of stubs in ROM and out in the field; so I'd be very
> reluctant to decree that they are no longer to be supported, even by
> using a different target name.

Let us give a different target name for a new thing.

>  Instead, we should continue to tighten
> up the new standard, but allow exceptions if truly necessary, on a
> case-by-case basis.  For instance, a couple letters can never be used
> for packet type because somebody already used them.  That's OK, we
> have lots more letters available to us, and they're now explicitly
> stated as being reserved for future use.
> 
> Actually, it would be interesting to find out about the lowest (sea
> floor?) and highest uses of GDB stubs (Mars?), smallest computer, most
> hostile environment, etc.  Who's got the best story?
> 
> 								Stan
> 

Thanks,

Aleksey