> On Jan 20, 2020, at 6:21 PM, Frank Ch. Eigler via Dwarf-Discuss > <dwarf-discuss@lists.dwarfstd.org> wrote: > > 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.
the "llvm-dwarfdump" binary in llvm.org <http://llvm.org/> has a "--verify" option that looks for issues in DWARF and reports errors. Not sure if there are any other tools out there that do this, but this would be a great check to add to any DWARF verifier. > > >> 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. As soon as optimization are in, the live ranges for many variables is quite sparse from my experience with most compilers. LLDB can detect when we are debugging optimized code. This is currently done by looking for the DW_AT_APPLE_optimized attribute on the DW_TAG_compile_unit, so this isn't available everywhere. But in general, if we know a program isn't optimized, then the variable locations are often live for much longer. But there is no guarantee that we can detect when things are optimized. > > > 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. I enjoy data mining DWARF for the information it contains, so the "llvm-dwarfdump --verify" is the main area I could see adding support for detecting when/if a compiler emits overlapping locations for variables. Let us know what you find out and what you end up doing. Very interesting to think about. > > > - FChE > > _______________________________________________ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
