Earlier quoted context omitted.
(I wrote a bunch of gcc's initial support for optimized code debugging, as well as the initial associated gdb support for evaluating location lists and expressions, which is what makes this all work under the covers) Given the invariant of "debug info does not affect optimization", you end up with plenty of cases where your only possible choices are "give the user a possibly wrong value for the variable" or "say the…
Could you clarify this comment a bit? Does GDB ever use current register contents to satisfy a request for a variable, or does it only use a value saved to the stack? That is, is the problem that you don't know when the register value is no longer valid, or that GDB doesn't actually associate the value with a register at all?
Over individual ranges, it even supports saying "this piece of the variable is in a register, this piece in memory, etc". Even at the per-bit level. You can evaluate complex turing-complete expressions to produce the value, including calling DWARF expression subroutines (the latter is fairly new)
GDB supports them all.
The underlying problem is multi-fold. 1. Computations get rewritten and rearranged in ways that do not affect the semantics of the program overall, but do of the intermediate states.
IE if you rewrite
a = b * 5
c = a * b
as
a = b * b
c = a * 5
assuming b = 3 the intermediate value of a is now 9 but in terms of the original code it was 15
A value of 45 probably would just confuse the programmer.
It is possible, with extensive enough tracking to solve the above problem for a significant set of cases
However, code movement and rearrangement make it not feasible to solve it in all (particularly around heavy loop optimization).
2. Variables also get partially coalesced/eliminated all the time in other interesting ways.
Turning applesauce back into apples is not possible in practice. I admit the theoretical possibility, but ...