Re: check for valid location of zero length dwarf block forms?

[Jack Howarth <howarth@bromo.med.uc.edu>]

On Sun, Nov 22, 2009 at 12:02:59PM +0100, Jan Kratochvil wrote:
> On Sat, 21 Nov 2009 04:42:58 +0100, Jack Howarth wrote:
> > ...as dwarf debug info containing an AT_location with
> > any block form having a zero length.
> 
> It is correct and equivalent according to the DWARF spec. and for gcc it seems
> to differentiate a case of known optimized-out value (=empty) vs. the case of
> gcc failed to describe the variable location (=missing).
> 	dwarflint: DW_AT_location being empty vs. missing check
> 	https://fedorahosted.org/pipermail/elfutils-devel/2009-March/000179.html
> 	https://fedorahosted.org/pipermail/elfutils-devel/2009-March/000180.html
> 
> 
> Regards,
> Jan

Jan,
   Is this being done in the following code from dwarf2out.c?

/* Resolve DW_OP_addr and DW_AT_const_value CONST_STRING arguments to
   an address in .rodata section if the string literal is emitted there,
   or remove the containing location list or replace DW_AT_const_value
   with DW_AT_location and empty location expression, if it isn't found
   in .rodata.  Similarly for SYMBOL_REFs, keep only those that refer
   to something that has been emitted in the current CU.  */

static void
resolve_addr (dw_die_ref die)
{
  dw_die_ref c;
  dw_attr_ref a;
  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;
        break;
      case dw_val_class_loc:
        if (!resolve_addr_in_expr (AT_loc (a)))
          a->dw_attr_val.v.val_loc = NULL;
        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;
          }
        break;
      default:
        break;
      }

  FOR_EACH_CHILD (die, c, resolve_addr (c));
}

The problem we have on darwin is that, while Apple will likely fix dsymutils
for Xcode 3.2 (Snow Leopard), it probably will remain broken for Tiger and
Leopard's devtools. So it would be helpful to find some way to suppress this
offending dwarf code on darwin in the cases were the variable has a valid location
but is zero length or doesn't have a location. Otherwise we won't be able to
generate dSYMs with dsymutil on those releases of Mac OS X with gcc 4.5 and
later.
           Jack