[PATCH] Fix early debug regression with DW_AT_string_length (PR debug/71906)

[Richard Biener]

On Fri, Jul 22, 2016 at 2:39 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Fri, Jul 22, 2016 at 2:08 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Fri, Jul 22, 2016 at 01:55:22PM +0200, Richard Biener wrote:
>>> > @@ -19201,18 +19205,70 @@ gen_array_type_die (tree type, dw_die_re
>>> >        if (size >= 0)
>>> >         add_AT_unsigned (array_die, DW_AT_byte_size, size);
>>> >        else if (TYPE_DOMAIN (type) != NULL_TREE
>>> > -              && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != NULL_TREE
>>> > -              && DECL_P (TYPE_MAX_VALUE (TYPE_DOMAIN (type))))
>>> > +              && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) != NULL_TREE)
>>> >         {
>>> >           tree szdecl = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
>>> > -         dw_loc_list_ref loc = loc_list_from_tree (szdecl, 2, NULL);
>>> > +         tree rszdecl = szdecl;
>>> > +         HOST_WIDE_INT rsize = 0;
>>> >
>>> >           size = int_size_in_bytes (TREE_TYPE (szdecl));
>>> > -         if (loc && size > 0)
>>> > +         if (!DECL_P (szdecl))
>>> >             {
>>> > -             add_AT_location_description (array_die, DW_AT_string_length, loc);
>>> > -             if (size != DWARF2_ADDR_SIZE)
>>> > -               add_AT_unsigned (array_die, DW_AT_byte_size, size);
>>> > +             if (TREE_CODE (szdecl) == INDIRECT_REF
>>>
>>> So I wonder how this can happen with variable-size type
>>> gimplification.  Shouldn't
>>> this be on, say, DECL_VALUE_EXPR of the DECL_P TYPE_MAX_VALUE?
>>
>> If you mean the INDIRECT_REF, that only happens with PARM_DECLs, and
>> conceptually a dereference of the argument is the right spot where the
>> length lives (if you reallocate the string with different character length,
>> then that is where you store the value.  If you add some artificial
>> decl that will hold the value of *_varb, then the trouble is that the
>> variable won't be assigned before the function prologue and most likely will
>> be optimized away anyway.
>
> True.  I wonder how other cases look like with the length not based on a
> parameter.

Note that reading the dwarf standard, it looks like it accepts a location
which means we could do an implicit location description using
DW_OP_stack_value which gives us access to arbitrary dwarf
expressions (and thus the possibility to handle it similar to VLAs).

But maybe I am missing something?  (now running into the issue
with LTO debug and gfortran.dg/save_5.f90 where during early debug
we emit a location that ends up refering to a symbol that might be
optimized away later - early debug cannot sanitize referenced symbols
via resolv_addr obviously).  Annotating the DIE late is also not
what I want to do as I'd need to pull in all type DIEs into the late CU
that way (well, at least selected ones, but I'm really trying to avoid
going down that route).

Thanks,
Richard.

>>>  <1><28d>: Abbrev Number: 19 (DW_TAG_string_type)
>>>  <1><28e>: Abbrev Number: 19 (DW_TAG_string_type)
>>>  <1><28f>: Abbrev Number: 6 (DW_TAG_pointer_type)
>>>
>>> so there is nothing to annotate with a location later.
>>
>> With the patch there will be DW_OP_call4 in 2 DW_AT_string_length
>> attributes and one DW_OP_call4; DW_OP_deref.
>>
>>> Note that even with GCC 5 'varb' didn't get a DW_AT_string_length,
>>> 'vara' did, though.
>>
>> Yeah, I've mentioned that in the mail.
>>
>>         Jakub