On Mon, Aug 01, 2016 at 12:44:30PM +0200, Richard Biener wrote:
> 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).
Sure. But for the DW_AT_string_length, the issue is that with early debug,
we want the attribute early, but locations within a function obviously
can be provided late, after the function is compiled.
Which is why the patch uses DW_OP_call4 as the holder of the information
that the string length is provided by the value of some variable.
In certain cases it can stay that way even during late debug, if the var
disappears or has no location info etc., then DW_AT_string_length is
dropped, or in other cases the location of the var is copied into the
attribute etc.
This is different from the VLA bounds in DW_AT_upper_bound etc., where
it is allowed to just refer to a DIE that holds the value (so we can stick
it into the attribute early and just supply the var's location later), for
DW_AT_string_length it is not allowed.
> 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).
In some cases like location of file scope vars, or this DW_AT_string_length,
you really need to adjust late the debug info created early, there is no
workaround for that.
Jakub
