Bootstrap failure of gcc-ss-20010409 in ia64

[Daniel Berlin]

Mark Mitchell <mark@codesourcery.com> writes:

> >>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:
> 
>     Jim> This was introduced by a C++ front end change by Mark
>     Jim> Mitchell on March 28.  See
>     Jim> < http://gcc.gnu.org/ml/gcc-bugs/2001-04/msg00081.html >.  See
>     Jim> also < http://gcc.gnu.org/ml/gcc-bugs/2001-03/msg00879.html >
>     Jim> from Alan Modra reporting the same bug for other targets.  I
>     Jim> believe all DWARF2 targets are broken at the moment.
> 
> Jim --
> 
>   I tried adding -gdwarf-2 to the command-line on i686-pc-linux-gnu,
> but I didn't see any problems with the stock 3.0 branch.

I also constantly use dwarf2 with C++, since i'm finishing up moving
some stuff from a GDB in C++ rewrite back to GDB, like location
expression evaluation at runtime, using the call frame info, redoing
some of the symbol structures, etc.

I can say for a certainty that all DWARF2 targets are not broken, in
the general case.  
I can also say for a certainty that they are also outputting proper
location expressions, even for complex cases.

Unless, of course, you have the -feliminate-dwarf2-dups flag
somewhere. It's currently outputting broken dwarf2.  It does't create
references to dies in another CU properly all the time. It ends up
getting the offset right, but in the wrong place (IE it's saying it's
at an offset in the current compilation unit, when it it's at that
offset in *another* compilation unit).  forcing it to use absolute die
references for everything fixes the problem, so it's certainly just
not marking something properly (It attempts to mark all the dies in
the current CU to figure out which are referencing things in other
CU's) , or something of the sort.


> 
>   I will try Alan's .ii file, which is apparently different from the
> checked-in version.  (But, of course, if the problem is related to the
> difference, then people shouldn't be seeing this elsewhere.)
> 
>   If you send me the usual (target triplet, preprocessed source,
> cc1plus command-line flags) I will try to figure it out.
> 

Ahh, actually, i think i know what's causing this.

Reordering the blocks and inlining is causing us to come across a type
or declaration, before we normally would (IE where "normal" is the
place where we generate
the type/decl die.)
This happens with templates and inlining, (or at least, it's the only
cases i've ever seen it happening), particularly with inlined
templated class members.
So it goes to add the abstract origin of the die, it tries to lookup
the decl/type of the origin, which we don't have.  I don't know if
this *should* ever happen, but it does.  So it aborts.  It's likely the cause is that
we are deferring outputting whatever the real origin is, but not the
actual inlined copy.  So when it goes to output the debug info, it
hits an inlined copy, with an origin that it hasn't processed yet, and
thus, doesn't have the die for in it's tables.


A quick fix would be to call gen_decl_die/gen_type_die if the lookups
fail, rather than aborting.
This is correct if the behavior above is correct.



>   Thanks,
>   
> --
> Mark Mitchell                   mark@codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com

-- 
In my house there's this light switch that doesn't do anything.
Every so often I would flick it on and off just to check.
Yesterday, I got a call from a woman in Germany.  She said, "Cut
it out."