On May 23, 2012, at 3:36 PM, Lawrence Crowl wrote:
> For variables that are not optimized out of memory, I think this
> can work. But if you need to go for registers,
Also trivial... Just one has to generate the context correctly. One has to
save off the registers and then in the context generator, synthesize them back
up. So, take a context in which a is in register 5, one can generate something
like:
void eval() {
register int a = __gdb_registers[5];
<snippet>
__gdb_registers[5] = a;
}
This preserves the value in register 5 from the gdb context at that point, and
even allows the user to write to such variables, and have that reflected in the
register file.
> or undo a variable elimination, the effort gets harder.
Yes, setting the value of a variable that has, for example, been removed due to
dce, is annoying. But I'll note it is annoying in gdb currently. I'd be happy
to introduce declarations that if used, lead to compile time errors. Darwin
for example has an unavailable attribute one can attach to a decl to ensure an
error is produced. gcc has deprecated, though, it is just a warning.
Now, for variables that can be computed from variables that are present, I'd
rather the optimizer explain how to produce the value given the state and for
gdb to producea context with that value into a read only variable. This
preserves for read access such variables that are gone. This is something that
gcc and gdb should be doing anyway... but don't.
> Yes, you essentially need to come close to sending the compiler's
> symbol tables through the debug information. I don't know of any
> compiler/debugger pair that is close to that capability.
:-) Not yet... Maybe never.
> I'm not saying that the task is impossible, only that there is a
> lot of work to do before we get there.
Yeah, I kinda think the gdb people are wimping out by not just implementing
__extension__ and ({}), which, I think get us most of the way there. Shh,
don't tell them I said that.
