[llvm-dev] [RFC] A value-tracking LiveDebugValues implementation

[Pavel Labath via llvm-dev]

On 22/06/2020 14:57, Jeremy Morse via llvm-dev wrote:
> Hi Adrian,
> 
>> quite a lot of work
> 
> Large amounts of credit should go to llvm-reduce, which was fundamental to
> getting any of this done,
> 
>> I've skimmed your implementation and it looks nice and well-documented.
> 
> The thing that worries me is the over-complicated lattices -- I didn't
> anticipate the problem, and there's a risk that it's more complex than it
> needs to be. As it sounds like getting this reviewed and landed is feasible,
> I'll write about that (and a worked example) in the review.
> 
>> I was wondering about potential downsides of tracking values. I noticed that
>> a surprising amount of developers like to modify variables in the debugger
>> [...]
> 
> This is really interesting, and as you say it's something that is already
> happening today. Consider this:
> 
>   #include <stdbool.h>
>   extern void ext(int);
>   extern bool extb(int, int);
>   void foo(int bar, int baz) {
>     ext(bar);
>     bool cont = true;
>     while (cont) {
>       cont = extb(bar, baz);
>     }
>   }
> 
> Compiled with a recent master -O2 -g and main() / other functions in another
> file, we get this disassembly and location list for 'bar':
> 
>    0x0000000000400483 <+3>:     mov    %esi,%ebx
>    0x0000000000400485 <+5>:     mov    %edi,%ebp
> => 0x0000000000400487 <+7>:     callq  0x4004d0 <ext>
> 
> DW_AT_location    (0x00000000:
>   [0x0000000000400480, 0x0000000000400487): DW_OP_reg5 RDI
>   [0x0000000000400487, 0x00000000004004a3): DW_OP_reg6 RBP)
> 
> Stepping through the function, we stop on the call to 'ext', and can set the
> value of 'bar', but because there are two locations (and LiveDebugValues picked
> the long term register $ebp rather than $edi), you can set "bar" but it has
> no effect on the call to 'ext'.
> 
> AFAIUI, this is never a problem at -O0 because there's only ever one location
> for a variable. With optimisations, and without a way to describe multiple
> locations for a variable in DWARF, I don't think it's generally solvable.

While, I don't want to give too much emphasis on being able to modify
variables in an optimized program (unoptimized programs are a different
story though), I feel obligated to jump in to say that DWARF already
does supports this scenario (Section 2.6.2 of DWARF5, page 43):
"""
The address ranges defined by the bounded location descriptions of a
location list may overlap. When they do, they describe a situation in
which an object exists simultaneously in more than one place.
"""

Now, I don't know of any debugger which actually does this, but in
theory a debugger could go and update all locations of a variable for a
given address instead of just the first one.

Changing only one of the CSE'd variables is obviously impossible, but
that is also something that could be mitigated by a very careful
debugger -- by checking whether any other variable happens to refer to
the same location and warning or aborting the modification.

cheers,
pavel