From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Mark Mitchell Cc: wilson@cygnus.com, schwab@suse.de, gcc@gcc.gnu.org Subject: Re: Bootstrap failure of gcc-ss-20010409 in ia64 Date: Wed, 11 Apr 2001 18:28:00 -0000 Message-id: References: <200104111947.MAA23080@wilson.cygnus.com> <20010411174320Q.mitchell@codesourcery.com> X-SW-Source: 2001-04/msg00513.html Mark Mitchell writes: > >>>>> "Jim" == Jim Wilson 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."