Re: Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin <dan@www.cgsoftware.com>]

On Tue, 17 Apr 2001, Mark Mitchell wrote:

> >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> 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
>