check for valid location of zero length dwarf block forms?

check for valid location of zero length dwarf block forms?

[Jack Howarth]

   Since the var-tracking-association code merge into
gcc trunk, we have had issues with Apple's dsymutil
program crashing on the code generated by the FSF
gcc trunk compiler...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473

Apple's dsymutil maintainer analyzed this issue...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c29

...as dwarf debug info containing an AT_location with
any block form having a zero length.
   The question is if these emitted dwarf codes are
accidental errors. Apple believes that if the variable
doesn't have a location, the DW_AT_location attribute
shouldn't be emitted. Also, if the variable does have
a valid location, then the length of zero is likely
a bug in dwarf2out.c.
   It might be worthwhile for the gdb developers to
look into this issue since there might be either
unnecessary dwarf output or incorrect dwarf output
that binutils doesn't recognize as such.
     Thanks in advance for any comments.
                 Jack

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

[Jan Kratochvil]

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

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

[Jack Howarth]

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

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

[Jan Kratochvil]

On Sun, 22 Nov 2009 21:21:48 +0100, Jack Howarth wrote:
>    Is this being done in the following code from dwarf2out.c?

Forwarded it to Dodji:

On Mon, 23 Nov 2009 10:57:55 +0100, Dodji Seketeli wrote:
# My understanding is that the code of resolve_addr makes sure that a
# DW_OP_addr or a DW_AT_const_value does _NOT_ point to a "junk" address.
# I.E. the function makes sure that if the address does not point to either a
# const string in .rodata or an address in the current CU (for SYMBOL_REFs),
# then:
# - the location list containing the DW_OP_addr is removed
#   or
# - the DW_AT_const_value is replaced by a DW_AT_location pointing to an
#   empty location expression.


> 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.

I think you can put some workaround
to dwarf2out.c (output_die <dw_val_class_loc>) but I did not try it.


Regards,
Jan

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

[Jack Howarth]

On Mon, Nov 23, 2009 at 01:42:26PM +0100, Jan Kratochvil wrote:
> On Sun, 22 Nov 2009 21:21:48 +0100, Jack Howarth wrote:
> >    Is this being done in the following code from dwarf2out.c?
> 
> Forwarded it to Dodji:
> 
> On Mon, 23 Nov 2009 10:57:55 +0100, Dodji Seketeli wrote:
> # My understanding is that the code of resolve_addr makes sure that a
> # DW_OP_addr or a DW_AT_const_value does _NOT_ point to a "junk" address.
> # I.E. the function makes sure that if the address does not point to either a
> # const string in .rodata or an address in the current CU (for SYMBOL_REFs),
> # then:
> # - the location list containing the DW_OP_addr is removed
> #   or
> # - the DW_AT_const_value is replaced by a DW_AT_location pointing to an
> #   empty location expression.
> 
> 
> > 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.
> 
> I think you can put some workaround
> to dwarf2out.c (output_die <dw_val_class_loc>) but I did not try it.
> 
> 
> Regards,
> Jan

Jon,
   Are you referring to the section in output_die() of gcc/dwarf2out.c which has...

       case dw_val_class_loc:
          size = size_of_locs (AT_loc (a));

          /* Output the block length for this list of location operations.  */
          dw2_asm_output_data (constant_size (size), size, "%s", name);

          output_loc_sequence (AT_loc (a));
          break;

I wonder if I could just do something like...

       case dw_val_class_loc:
          size = size_of_locs (AT_loc (a));

          /* Output the block length for this list of location operations.  */
          dw2_asm_output_data (constant_size (size), size, "%s", name);

          if (dwarf_strict && (size == 0)) 
                 break;
          else 
                output_loc_sequence (AT_loc (a));
          break;

Since only darwin currently defaults to dwarf_strict.
                 Jack

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

[Cary Coutant]

> I wonder if I could just do something like...
>
>       case dw_val_class_loc:
>          size = size_of_locs (AT_loc (a));
>
>          /* Output the block length for this list of location operations.  */
>          dw2_asm_output_data (constant_size (size), size, "%s", name);
>
>          if (dwarf_strict && (size == 0))
>                 break;
>          else
>                output_loc_sequence (AT_loc (a));
>          break;

By the time we get to output_die(), the abbrev code has already been
chosen, DIE offsets have been calculated, and a DW_AT_location
attribute of a known size is expected. Skipping it completely here
will break the DWARF output.

I think what you would want to do instead is change resolve_addr()
either to remove the DW_AT_location attribute from the DIE instead of
setting dw_attr_val.v.val_loc to NULL, or to set dw_attr_val.v.val_loc
to a DWARF expression containing nothing but DW_OP_nop. In the
dw_val_class_loc_list case, I'm not sure if the Apple tool is picky
enough to complain about zero-length location expressions there, too;
if it is, you'll either need to remove a NULL expr from the location
list, or set it to a DW_OP_nop as well.

I haven't looked to see if there are other places besides
resolve_addr() that might generate a null location expression.

In the long run, though, the Apple tools should be fixed. An empty
DWARF location expression is well defined and valid.

-cary