This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [VTA, PR41473] drop NULL locations from lists
On Thu, Nov 26, 2009 at 07:13:36AM -0200, Alexandre Oliva wrote:
> On Nov 24, 2009, Jack Howarth <howarth@bromo.med.uc.edu> 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 <howarth@bromo.med.uc.edu> 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 <aoliva@redhat.com>
>
> 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