11 ms·

(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 expressi

(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 value does not exist anymore". Most of the time, the latter is done instead of the former. You also unfortunately cannot just mark them so the debugger tells you "this may be wrong, it may be right, good luck". Historically, compilers tried doing the former, users complained enough that they switched to doing the latter.

mehrdadn 8y ago
I wonder if the error message could just be better. Instead of using the excuse that the variable has been "optimized away", maybe gdb should just say it "cannot determine variable value due to optimization".
- saagarjha 8y ago
  Or even: this variable has likely been optimized away, but you might still find it in $rax.
nkurz 8y ago
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?
- DannyBee 8y ago
  So, DWARF tries to provide extensive support for all possible options you can think of to do things like say "a variable is live int his range, have this value in this range, and is dead in this range" 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 ...

mehrdadn 8y ago

I wonder if the error message could just be better. Instead of using the excuse that the variable has been "optimized away", maybe gdb should just say it "cannot determine variable value due to optimization".

saagarjha 8y ago
Or even: this variable has likely been optimized away, but you might still find it in $rax.

nkurz 8y ago

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?

DannyBee 8y ago
So, DWARF tries to provide extensive support for all possible options you can think of to do things like say "a variable is live int his range, have this value in this range, and is dead in this range" 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 ...