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

[Frank Ch. Eigler]

Hi -

> > - ... and undoubtedly other complications exist!
> 
> Interesting question.

Thanks!

We have been thinking in similar directions generally as y'all.


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

> [...]
> Presumably, a debugger could check that location lists do not
> overlap.

This could nevertheless be a valid heuristic to detect the case.


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


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


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.


- FChE