DWARF Standard

Section 2.5.1.5, pg 36
With the link time optimization debug info generation where we want to emit 
debug info for types/variables etc. early and only afterwards ammend it with 
additional information (locations etc.), we ran into a problem similar to 
http://www.dwarfstd.org/issues/160811.1.html, but where we need the 
value of some local variable (in http://gcc.gnu.org/PR77589 for 
DW_AT_byte_stride location expression that is on a type).  
DW_OP_call4/call_ref aren't IMHO usable here, because to use those in the 
middle of DWARF expressions it is needed that the referenced DIE's 
DW_AT_location is actually a valid DWARF expression (and additionally that 
it as a result adds exactly one new value on the DWARF stack and ideally 
doesn't use any earlier stack slots).
That is not the case in many cases though, the variable could have DW_OP_reg* 
as its location description, or DWARF expression followed by DW_OP_stack_value,
or could not have DW_AT_location at all and have instead DW_AT_const_value, 
etc.  When the producer can see the DW_AT_location of the DIE referenced by 
DW_OP_call* together with the DWARF expression where it wants to use DW_OP_call*, 
it can either inline the expression there, tweak it for the DW_OP_stack_value 
removal, transform DW_OP_reg* into DW_OP_breg* 0, etc.  But if it is different 
producer that emits the DW_OP_call* and different one that adds DW_AT_location 
for the referenced var, then this doesn't really work.

I think it would be useful to have a DW_OP_call* like operator that would not 
evaluate the expression from the referenced DIE, but where the producer would 
compute the variable's value and push that value into DWARF stack.  Most 
likely it would make sense only for integral variables, but that is most 
likely all where it is needed.