Re: [patch 10/10] debug-early merge: compiler proper

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, May 28, 2015 at 10:35 PM, Jason Merrill <jason@redhat.com> wrote:
> On 05/28/2015 02:53 PM, Aldy Hernandez wrote:
>>
>> On 05/27/2015 08:39 AM, Jason Merrill wrote:
>>>
>>> On 05/20/2015 11:50 AM, Aldy Hernandez wrote:
>>
>>
>>>> +  /* Fill in the size of variable-length fields in late dwarf.  */
>>>> +  if (TREE_ASM_WRITTEN (type)
>>>> +      && !early_dwarf_dumping)
>>>> +    {
>>>> +      tree member;
>>>> +      for (member = TYPE_FIELDS (type); member; member = DECL_CHAIN
>>>> (member))
>>>> +    fill_variable_array_bounds (TREE_TYPE (member));
>>>> +      return;
>>>> +    }
>>>
>>>
>>> Why is this happening in late dwarf?  I'm concerned that front-end
>>> information that is necessary to do this might be lost by that point.
>>
>>
>> I thought only after the optimizations had run their course would we be
>> guaranteed to have accurate bound information.  At least, that's what my
>> experience showed.
>
>
> Hmm, I'm don't know why optimizations would change the representation of the
> array type.

Correct.  It works fine with the LTO prototype I did apart from gdb not really
getting the association between the early DIEs

 <0><166>: Abbrev Number: 1 (DW_TAG_compile_unit)
...
 <1><1e5>: Abbrev Number: 6 (DW_TAG_subprogram)
...
 <2><1fc>: Abbrev Number: 8 (DW_TAG_variable)
    <1fd>   DW_AT_type        : <0x1d7>
    <201>   DW_AT_artificial  : 1
    <201>   DW_AT_declaration : 1
 <2><201>: Abbrev Number: 3 (DW_TAG_variable)
    <202>   DW_AT_name        : a
    <204>   DW_AT_decl_file   : 1
    <205>   DW_AT_decl_line   : 15
    <206>   DW_AT_type        : <0x20b>
 <2><20a>: Abbrev Number: 0
 <1><20b>: Abbrev Number: 9 (DW_TAG_array_type)
    <20c>   DW_AT_type        : <0x21e>
    <210>   DW_AT_sibling     : <0x21e>
 <2><214>: Abbrev Number: 10 (DW_TAG_subrange_type)
    <215>   DW_AT_type        : <0x1d7>
    <219>   DW_AT_upper_bound : <0x1fc>

and the late DIEs annotating the above

 <0><24c>: Abbrev Number: 1 (DW_TAG_compile_unit)
...
 <1><30c>: Abbrev Number: 3 (DW_TAG_subprogram)
    <30d>   DW_AT_abstract_origin: <0x1e5>
...
 <2><32e>: Abbrev Number: 4 (DW_TAG_variable)
    <32f>   DW_AT_abstract_origin: <0x1fc>
    <333>   DW_AT_location    : 11 byte block: 75 1 8 20 24 8 20 26 31
1c 9f    (DW_OP_breg5 (rdi): 1; DW_OP_const1u: 32; DW_OP_shl;
DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1; DW_OP_minus;
DW_OP_stack_value)
 <2><33f>: Abbrev Number: 11 (DW_TAG_variable)
    <340>   DW_AT_abstract_origin: <0x201>
<2><344>: Abbrev Number: 0
 <1><345>: Abbrev Number: 12 (DW_TAG_subprogram)

so it fails to jump through hoops when looking up the type of 'a'
seeing the annotation
to the variable used in the array types upper bound... (probably
expected, I'd probably
need to pull down the type, and the subrange-type as well, even though I do not
annotate them).

Or we can teach gdb to jump through the hoops (basically collect all
additional info
that a subprogram DIE children provide to the subprogram abstract
origin children DIEs
somewhen in advance...)

It would be a shame if I really had to create "empty" references to
all the dependence
chain formed via types from the array variable to the array subrange
type upper bound.

Richard.

>>>> +      /* Variable-length types may be incomplete even if
>>>> +     TREE_ASM_WRITTEN.  For such types, fall through to
>>>> +     gen_array_type_die() and possibly fill in
>>>> +     DW_AT_{upper,lower}_bound attributes.  */
>>>> +      if ((TREE_CODE (type) != ARRAY_TYPE
>>>> +       && TREE_CODE (type) != RECORD_TYPE
>>>> +       && TREE_CODE (type) != UNION_TYPE
>>>> +       && TREE_CODE (type) != QUAL_UNION_TYPE)
>>>> +      || (TYPE_SIZE (type)
>>>> +          && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST))
>>>
>>>
>>> Similarly, why check for INTEGER_CST here?
>>
>>
>> The INTEGER_CST check was supposed to mean "we have bound information
>> already, no need to look further".
>>
>> I guess we could have a variable length bound that does not decay to a
>> constant.
>
>
> Right.  I would expect that to usually be the case with VLAs.
>
>> Perhaps I could check the presence of a cached DIE with a
>> type DIE containing a DW_TAG_subrange_type *and*
>> DW_AT_{lower,upper}_bound ??.  Basically I just want to add bound
>> information, if available and not already present.
>>
>> Suggestions?
>
>
> I'm still not sure why we can't just emit bound info in early dwarf. Can you
> be more specific about the optimization thing?
>
> Jason
>