>There should be no circumstance where the value of some variable has been optimized out. That's what optimization does. If you have `x := 1 ; y := 2 ; z := x

>There should be no circumstance where the value of some variable has been optimized out. That's what optimization does. If you have `x := 1 ; y := 2 ; z := x + y ; print z ;` optimizing will just leave you `print 3` in most languages. There just won't be x, y or z values after the optimizations are done. If a value is to be calculated then passed down some stack of functions, but during optimization the value is folded into a constant, then the functions rewritten to use the determined constant and then the now unused parameters are dropped, what is it supposed to do? Pretend the value is still there? Faking stack frame details seems particularly counter to what I want a debugger to be doing while I step through code. Leaving the variables in place would slow and bloat the generated code. >common operations like printing arrays or memory being hard and obscure obscure, perhaps. I did have to look up array printing syntax, as I usually only print variables or specific array entries. It's not hard that I see, however. $ gdb a.out (gdb) start hello world this is a test Temporary breakpoint 1 at 0x4004da Starting program: /some/path/a.out hello world this is a test Temporary breakpoint 1, 0x00000000004004da in main () (gdb) step Single stepping until exit from function main, which has no line number information. __libc_start_main (main=0x4004d6 <main>, argc=7, argv=0x7fffffffdd58, init=<optimized out>, fini=<optimized out>, rtld_fini= <optimized out>, stack_end=0x7fffffffdd48) at ../csu/libc-start.c:325 325 ../csu/libc-start.c: No such file or directory. (gdb) print argc $1 = 7 (gdb) print *argv@argc $2 = {0x7fffffffe0f0 "/some/path/a.out", 0x7fffffffe10b "hello", 0x7fffffffe111 "world", 0x7fffffffe117 "this", 0x7fffffffe11c "is", 0x7fffffffe11f "a", 0x7fffffffe121 "test"} (gdb)