From mboxrd@z Thu Jan 1 00:00:00 1970 From: Todd Whitesel To: mark@codesourcery.com (Mark Mitchell) Cc: gdb@sourceware.cygnus.com (GDB Developers) Subject: Re: PATCH to buildsym.c Date: Mon, 06 Dec 1999 15:32:00 -0000 Message-id: <199912062332.PAA24715@alabama.wrs.com> References: <19991201143603Z.mitchell@codesourcery.com> X-SW-Source: 1999-q4/msg00460.html > 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 To: Stan Shebs Cc: gdb@sourceware.cygnus.com Subject: Re: bugs in remote.c Date: Mon, 06 Dec 1999 16:54:00 -0000 Message-id: 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 > > 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