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

[Michael Eager]

On 1/20/20 6:21 PM, Frank Ch. Eigler via Dwarf-Discuss wrote:
>> Complication 2: The compiler reuses variable locations at the same PC. This
>> seems to be a compiler bug.
> 
> (Actually, this could be a valid optimization, e.g.:
> 
>             int a = expression;
>             int b = expression;
>    >>>>>
>             /* use/modify a */
>             /* use/modify b */
> 
> at that point, if $expression is a pure function, a compiler
> could evaluate it once and reuse the value.  It could do this
> by temporarily storing both a and b in the same register, and
> only separating the variables afterwards.

Yes, where b is a copy of a, they can occupy the same location.  That 
does raise the question about what happens when the user instructs the 
debugger to change b, expecting that a will not be affected.

>> Complication 3a: That the value of a variable has been fetched for a
>> computation before the debugger modifies it.  This is more complicated. The
>> live range of the variable is accurate, but its value has been used before
>> the current PC.  DWARF does not include descriptions of data flow or
>> indicate where variables are fetched, so there is no information that a
>> debugger can use to assure that a modified value is actually used.
> 
> Yeah, and in the absence of dataflow metadata, tools like dyninst must
> try to reverse-engineer the dataflow in order to perform binary
> rewriting.  Is this something way out of forseeable dwarf scope?

I think that describing the data flow would be large.  Essentially, copy 
most of the IR data into DWARF.  If you have ideas about how to 
represent a compressed data flow graph, let us know.  There might only 
be a need for a limited subset.

>> There are a lot of issues with a debugger modifying a program while it is
>> running.  A debugger can make essentially unbounded changes to the program
>> state.  Some of these may work as expected, some may not, and it is unclear
>> how a debugger would be able to know the difference.
> 
> This is the key question: how can a tool know what is safe.  While the
> trivial case of assuming every write is unsafe is not helpful :-), it
> could be okay to have fairly conservative heuristics, known-partial
> information, and rely on only clear signals to enable write
> operations.

I can't think of any heuristic that would work, unless the debugger does 
an analysis of the generated code to find where variables are actively 
being used.  It also seems most likely that a user might want to modify 
variable exactly when they are being used, not where they are quiescent.

> Anyway, it sounds like the next step is on us to analyze & prototype
> in a compiler (gcc?).  I'd also appreciate authors of other dwarf
> consumer and producer tools to mention whether they have considered
> this area, so as to collect a census.


-- 
Michael Eager    eager at eagerm.com
1960 Park Blvd., Palo Alto, CA 94306