https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71906
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Better testcase that shows more cases:
program pr71906
character(len=8) :: vard
character(len=:), allocatable :: vare
type t
character(len=:), allocatable :: f
end type
type(t) :: varf
allocate(character(len=10) :: vare)
allocate(character(len=9) :: varf%f)
vare = 'foo'
call foo (vard, vare, varf)
contains
subroutine foo (vara, varb, varc)
character(len=*) :: vara
character(len=:), allocatable :: varb
type(t) :: varc
vara = 'bar'
varb = 'baz'
varc%f = 'str'
end subroutine
end program pr71906
The problem is that DW_AT_string_length attribute allows just exprloc or
loclistptr classes. Even GCC 5.x doesn't handle here the varb case, and
varc/varf case. For varb the string length is *.varb (.varb being an
artificial argument), for varc/varf the struct has fields f and _f_length.
With the early debug changes, nothing works anymore.
While DW_AT_upper_bound etc. allows a DIE ref, so even with early debug we can
put something (the DIE ref) into the attribute, for DW_AT_string_length we only
have a decl (VAR_DECL/PARM_DECL/FIELD_DECL) or INDIRECT_REF of it, the DIE for
it might not be created yet and even if it is, obviously it has no location
information yet (that only appears when we actually compile corresponding
function).
I've tried to use DW_OP_call4 in DW_AT_string_length, but I bet that will only
work if the artificial length vars have a DWARF expression in their
DW_AT_location (or DWARF expression in their DW_AT_location location list for
the current location), having something that ends up with DW_OP_stack_value
etc. is not valid DWARF I bet.
Another thing is the type of the f field.
The string length in that case is present in the same aggregate, but is not
necessarily adjacent to the f field (e.g. if one puts integer :: i field after
f, then the order is f, i, _f_length).
Not sure what to emit in those DW_AT_string_length for it at all right now.
Looking for what ICC emits, it doesn't emit anything useful for f, but for
varb and vare it emits
DW_OP_push_object_address; DW_OP_constu: 8; DW_OP_plus
as DW_AT_string_length. It is unclear what they expect to be
DW_OP_push_object_address here, and what/if anything GDB expands it. Is it the
address of the object that has the string type, or the address of the object
that has DW_TAG_pointer_type to DW_TAG_string_type, something else?
