From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Mark Mitchell Cc: , Subject: Re: Bootstrap failure of gcc-ss-20010409 in ia64 Date: Tue, 17 Apr 2001 08:57:00 -0000 Message-id: References: <20010417082155Y.mitchell@codesourcery.com> X-SW-Source: 2001-04/msg00767.html On Tue, 17 Apr 2001, Mark Mitchell wrote: > >>>>> "Jim" == Jim Wilson writes: > > Jim> Not emitting the abstract origin attribute would be easy. > Jim> This will give a die with no type or size info, which is > Jim> pretty useless. I suspect gdb will give a reasonable error > Jim> message instead of failing, but haven't tried it yet. > > Jim> For a slightly more complicated change, we could check to see > Jim> if the abstract origin attribute was emitted, and if not, > Jim> then treat it like a non-inlined local variable. This would > Jim> allow the user to still be able to look at the variable, but > Jim> the output would be a little confusing since the debugger > Jim> would claim that we have a variable that doesn't exist in the > Jim> source code. > > I think either of these two alternatives would be fine. > > In my experience, using GDB to debug optimized, heavily inlined code > really has never worked. You tend not to be able to see variables, > you tend to find that step/next work oddly, and often you end up > jumping entirely out of the function spontaneously. Just a note, for the "long run". This is something i'm seriously working on currently. It's why I sent patches to support location lists for dwarf2 (well, one of the reasons, anyway). I already have modified loop unrolling to keep track of the approriate things so that when combined with a patch to start using location lists for my modified range rtlin dwarf2out.c (I removed some useless things from the range info, since we no longer need to be tracking state for the register allocator, just knowing enough to produce the debug info), and can successfully handle location lists, and evaluation of them at runtiome, in gdb. So when the IV gets split into 4, we still can print the right value at the right place, although step and next are still a little confusing. I'm working on that too, but it's a little trickier of a change (I can already read and do some stuff with the call frame info, which is basically necessary to be able to treat inline functions as if they had their own frame), so it's taking time. Obviously, i'm not shooting for the 3.0 timeframe, i just wanted to make sure nobody thought the "long run" was 5 years from now, when it's probably 7 or 8 months. > > So, I guess I don't think this will be a major inconvenience to > anyone, relative to the current state. > > In the long run, we should do better, but it sounds like these changes > would do the trick for GCC 3.0. At this point, we have to be looking > for minimalist solutions. > > Thanks, > > -- > Mark Mitchell mark@codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com >