[Dwarf-Discuss] variable locations - safe use as lvalues

[Adrian Prantl]

> On Jan 20, 2020, at 2:20 PM, Frank Ch. Eigler via Dwarf-Discuss <dwarf-discuss at lists.dwarfstd.org> wrote:
> 
> Hi -
> 
> I have a question about variable location lists, but not their
> encoding, the use they are suitable for.  The basic debugging scenario
> is just reading variable values, for which this is fine, especially
> when high-quality compilers emit exquisitely detailed data for their
> optimized code.
> 
> But what about writes - as though one could edit the program to insert
> an assignment, and resume?  A whole slew of complications come up:
> 
> - trying to modify a variable permanently, but the compiler only
>  emitted -some- of its locations
> 
> - trying to modify a variable (and only one), but the compiler put two
>  variables into the same location at that PC
> 
> - expressions using that value as input might have already started
>  to be computed, so it may be too late to change it at the PC
>  in question
> 
> - ... and undoubtedly other complications exist!
> 
> A debugger cannot currently be told that any particular variable
> location expression is safe to use as an lvalue, something roughly
> "exclusive, exhaustive, -O0-equivalent".  I believe most debuggers
> don't even handle the multiple-locations case for writes at all.  I
> don't know why - assume complications are rare?  or we have kind of
> papered over the problem?
> 
> As a DWARF standard level matter, descriptive rather than prescriptive
> as it is, what might be the minimum extension required to communicate
> lvalue-safety to a debugger?  A DW_OP_lvalue_safe assertive wrapper
> around a real expression?


My reading of the Location Description was that only Single Simple Memory and Register Location Descriptions (2.6.1.1.2, 2.6.1.1.3) are safe to use as L-values in the debugger. In practice, even that may be difficult, since even without optimizations a too-clever register allocator or instruction selector may insert a copy of a register or may re-use a previously loaded copy of a memory location instead of loading it again for each use. Something like a DW_OP_describes_all_locations flag would be needed to communicate what the compiler did to the debugger.

>From my experience with LLVM, it might take some work to implement this correctly, since compilers typically only track one value for debug info purposes and don't yet have the infrastructure to keep track of alternative locations.

-- adrian