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 ea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
