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

[David Blaikie via llvm-dev]

On Tue, Jun 23, 2020 at 5:38 AM Pavel Labath via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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.
> """

Yup +1

> 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.

That'd be tricky to do in practice & probably involve more than
checking other location descriptions - possible that the compiler
shared storage in some way (maybe not with another variable, maybe
with the return value or a parameter value) & modifying that storage
would produce a different return value/other changes in program
behavior that were unintended.

I'd thought DWARF had some, at least theoretical (like teh
simultaneous location support), mechanism to describe storage a
consumer could realistically mutate & get something like the
observable behavior as distinct from just the immutable value. But at
a glance I don't find any wording like that. In the absence of that,
yeah, it's basically "if you use a debugger to mutate state in an
optimized program... don't bet on the behavior being in any way
reliable/sensible/consistent".

- Dave