Jakub Jelinek <jakub at gcc dot> changed:

           What    |Removed                     |Added
                 CC|                            |aldyh at gcc dot,
                   |                            |rguenth at gcc dot

--- Comment #3 from Jakub Jelinek <jakub at gcc dot> ---
I'm afraid this is similar to the DW_AT_string_length troubles (but not to the
direct reference to a DIE of some local variable, which can be besides the hack
we have now solved using DWARF extension, but to the indirect one where we only
have the hack which won't really work for LTO).

In this case, when the FE fills in the array_descr_info, it fills in:
(gdb) p debug_generic_stmt (info->dimen[0].lower_bound)
*(D#1 + 32);

$4 = void
(gdb) p debug_generic_stmt (info->dimen[0].upper_bound)
*(D#1 + 40);

$5 = void
(gdb) p debug_generic_stmt (info->dimen[0].stride)
*(D#1 + 24) * span.0;

The first two are representable just fine,
        .uleb128 0x4    # DW_AT_lower_bound
        .byte   0x97    # DW_OP_push_object_address
        .byte   0x23    # DW_OP_plus_uconst
        .uleb128 0x20
        .byte   0x6     # DW_OP_deref
        .uleb128 0x4    # DW_AT_upper_bound
        .byte   0x97    # DW_OP_push_object_address
        .byte   0x23    # DW_OP_plus_uconst
        .uleb128 0x28
        .byte   0x6     # DW_OP_deref
but the problem is with the stride, it refers to a local variable, but
obviously during early debug we don't really have location description for that
variable.  And like for DW_AT_string_lenght, DW_OP_call{2,4,_ref} isn't the
100% answer here, because those expect the referenced DIE has DWARF expression
rather than location description.  So we'd need DW_OP_variable_value or
something similar.

Reply via email to