https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77589
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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
and
.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.
