From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: dan@cgsoftware.com Cc: wilson@cygnus.com, gcc@gcc.gnu.org Subject: Re: Bootstrap failure of gcc-ss-20010409 in ia64 Date: Tue, 17 Apr 2001 16:36:00 -0000 Message-id: <20010417163553W.mitchell@codesourcery.com> References: <200104171801.LAA14512@wilson.cygnus.com> <20010417153759J.mitchell@codesourcery.com> X-SW-Source: 2001-04/msg00821.html >>>>> "Daniel" == Daniel Berlin writes: Daniel> This is the only case that is "unattainable". You can I'm all for all the fancy DWARF2 stuff; I'd love to have it, and I'm glad you're working on it. (I was actually an advocate of getting rid of stabs, in favor of DWARF, a couple of years ago on these lists). But, there are other things that are very hard to do, often because something is just not there in the compiler output. Like instantiate a class that the compiler didn't see a use of, and therefore didn't emit debugging information for. Or set a breakpoint at a line that has been optimized away. Or call an inlined function from the debugger if no out-of-line instance was emitted by the compiler. Or making it easy for a programmer to follow the control flow with `step' in the debugger when the compiler has reordered the code. Some of these things might be important; some might not. Some, you could simulate. But, there are problems that are hard. Bottom line: a statement like this Please, don't claim something is unattainable when i've *seen* it done with my own eyes. is more inflammatory than it needs to be, and suggests that I don't know about these things. The point is that debugging optimized code will always be harder thatn debugging unoptimized code. It would be good if are debug information was perfect for optimized code. But, it's more important that it be perfect for unoptimized code (and I bet it's not!), and it's even more important that we generate correct code (which I know we don't always). Not to mention improving GDB to have a better user interface, better stability, etc. (Thanks to you for working on this!) It's a question of priorities, cost-benefit analysis, etc. Is it worth the effort (both programmer-time and compiler-time) to do what Jim suggested, or is better just to punt? I think we all agree punting is OK for the 3.0 branch. The question is whether to punt on the 3.1 mainline, or not. If we do, then some people argue that we are less likely to fix the bug. On the other hand, if we do not punt, then if we don't fix the bug, we must remember to insall the punt again on the 3.1 release branch, when we get there. And meanwhile some programs will crash on the mainline. Personally, I would prefer that we file a bug in GNATS (debugging info wrong; here's a test-case) and install the punt on both the mainline and the branch. That adheres to the principle of trying to keep things working as much as possible so that a) it's easier to do releases, and b) it's easier for everyone to test the compiler and work to improve it. A broken compiler may serve as a good reminder, but it also makes life difficult for people working on unrelated tasks. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com