From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29239 invoked by alias); 29 Nov 2009 17:56:41 -0000 Received: (qmail 29227 invoked by uid 22791); 29 Nov 2009 17:56:40 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from bromo.med.uc.edu (HELO bromo.med.uc.edu) (129.137.3.146) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Sun, 29 Nov 2009 17:56:35 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id 3E956B0048; Sun, 29 Nov 2009 12:56:33 -0500 (EST) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id nATHuWdW013229; Sun, 29 Nov 2009 12:56:32 -0500 Date: Sun, 29 Nov 2009 19:08:00 -0000 From: Jack Howarth To: Alexandre Oliva Cc: gcc-patches@gcc.gnu.org Subject: Re: [VTA, PR41473] drop NULL locations from lists Message-ID: <20091129175632.GC13043@bromo.med.uc.edu> References: <20091123230646.GA29685@bromo.med.uc.edu> <20091124023954.GB30884@bromo.med.uc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg01624.txt.bz2 On Thu, Nov 26, 2009 at 07:13:36AM -0200, Alexandre Oliva wrote: > On Nov 24, 2009, Jack Howarth wrote: > > > I am uncertain if the stock dwarfdump will provide the necessary > > information to find any residual zero locations. > > That doesn't matter, I don't think I'd be able to use it in a > cross-compilation setting anyway. > > On Nov 25, 2009, Jack Howarth wrote: > > > I've uploaded assembly files (generated with -dA) as well as the > > preprocessed source for all the object files in the FSF gcc trunk > > build with your proosed patch... > > > http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01329.html > > > that still emit zero AT_LOCATIONS and cause dsymutil to assert. > > These all seem to be of the form... > > > .byte 0x0 # DW_AT_location > > Thanks. I picked up one of the testcases you posted and found out where > that location information comes from: it was a DWARF2-representable > location expression that referenced a symbol that, in the end, wasn't > emitted. > > We used to simply zero out the location information. With the patch > below, we'll remove attributes and location list entries that fail to > resolve. > > Will you please give it a try and let me know whether any other issues > remain? > > for gcc/ChangeLog > from Alexandre Oliva > > PR debug/41473 > * dwarf2out.c (AT_loc_list_ptr): New. > (resolve_addr): Remove unresolved attributes and loc_list entries. > > Index: gcc/dwarf2out.c > =================================================================== > --- gcc/dwarf2out.c.orig 2009-11-26 06:40:48.000000000 -0200 > +++ gcc/dwarf2out.c 2009-11-26 07:04:41.000000000 -0200 > @@ -7206,6 +7206,13 @@ AT_loc_list (dw_attr_ref a) > return a->dw_attr_val.v.val_loc_list; > } > > +static inline dw_loc_list_ref * > +AT_loc_list_ptr (dw_attr_ref a) > +{ > + gcc_assert (a && AT_class (a) == dw_val_class_loc_list); > + return &a->dw_attr_val.v.val_loc_list; > +} > + > /* Add an address constant attribute value to a DIE. */ > > static inline void > @@ -20961,28 +20968,48 @@ resolve_addr (dw_die_ref die) > { > dw_die_ref c; > dw_attr_ref a; > - dw_loc_list_ref curr; > + dw_loc_list_ref *curr; > unsigned ix; > > for (ix = 0; VEC_iterate (dw_attr_node, die->die_attr, ix, a); ix++) > switch (AT_class (a)) > { > case dw_val_class_loc_list: > - for (curr = AT_loc_list (a); curr != NULL; curr = curr->dw_loc_next) > - if (!resolve_addr_in_expr (curr->expr)) > - curr->expr = NULL; > + curr = AT_loc_list_ptr (a); > + while (*curr) > + { > + if (!resolve_addr_in_expr ((*curr)->expr)) > + { > + dw_loc_list_ref next = (*curr)->dw_loc_next; > + if (next && (*curr)->ll_symbol) > + { > + gcc_assert (!next->ll_symbol); > + next->ll_symbol = (*curr)->ll_symbol; > + } > + *curr = next; > + } > + else > + curr = &(*curr)->dw_loc_next; > + } > + if (!AT_loc_list (a)) > + { > + remove_AT (die, a->dw_attr); > + ix--; > + } > break; > case dw_val_class_loc: > if (!resolve_addr_in_expr (AT_loc (a))) > - a->dw_attr_val.v.val_loc = NULL; > + { > + remove_AT (die, a->dw_attr); > + ix--; > + } > break; > case dw_val_class_addr: > if (a->dw_attr == DW_AT_const_value > && resolve_one_addr (&a->dw_attr_val.v.val_addr, NULL)) > { > - a->dw_attr = DW_AT_location; > - a->dw_attr_val.val_class = dw_val_class_loc; > - a->dw_attr_val.v.val_loc = NULL; > + remove_AT (die, a->dw_attr); > + ix--; > } > break; > default: > > -- > Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ > You must be the change you wish to see in the world. -- Gandhi > Be Free! -- http://FSFLA.org/ FSF Latin America board member > Free Software Evangelist Red Hat Brazil Compiler Engineer Alexandre, A couple other users, Dominique d'Humieres and Andreas Tobler, have tried the combination of the two patches... http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01329.html http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01452.html and it appears to be eliminating the dsymutil asserts for everyone. Can we get this into gcc trunk before it leaves stage 3? It should be okay afterwards since PR41473 does represent a regresssion from gcc 4.4.2 on darwin. I just wanted to make certain. These patches have been a huge help in allowing me to debug PR41991 in gcc trunk since without them either the debug info in the dSYM will be missing or corrupted. Thanks in advance. Jack