Hacker News Reader

Comment by userbinator | Hacker News Reader

I wonder how much this will help with a very common experience:

    (gdb) p x
    $3 = <value optimized out>
    (gdb) p $ecx
    $4 = 1234

"What do you mean, value is optimized out!?!? It's sitting right there in the bloody register!"

I've long since grown accustomed to mentally decompiling the Asm and finding the correspondence to the source from that instead.

View on HN

> "What do you mean, value is optimized out!?!? It's sitting right there in the bloody register!"

It's the biggest problem I have with debuggers. Interestingly, with rr you can usually reverse-stepi a little, and get the value from a slightly earlier time, where its location was known to the debug info. A life saver, although depending on what the code does to the value, that might not help entirely. If only rr was available on all platforms... I guess TTD can help similarly on Windows.

WinDBG Preview's TTD works really well, it's a really solid alternative to rr... if you can get past windbg's terrible ui/ux and piss poor discoverability.

I really hope someone makes the TTD stuff available from vscode (or even better, from IDA) so I can use the awesome core functionality without the terrible frontend.

The curious thing is that is isn't a bug in the debugger itself usually. It's the optimizer process that doesn't leave proper instructions of where "x" is at this point.

This specific paper won't. This detects incorrect debug information and it considers debug information loss to be correct.

It's technically possible to give perfect debug information even with a highly optimized binary. In a typical Linux/BSD ELF file the debug information is stored as a DWARF program that effectively emulates the state of all the registers in the target machine, and that program gets executed from the saved frame state of the current function to produce the state at the current breakpoint complete with tracking backpointers into the source. To track all information properly would require much much more state to be preserved over optimization passes and saved with each executable. The end result would effectively end up embedding the compiler internal state inside each and every target executable. The cost, of course, would be massive (terabyte) executables that take minutes or so to execute every step in the debugger, and compile times orders of magnitude greater than they are today.

The current assumption is that the programmer knows enough about what they are doing and how their tools work under the hood that they can live with the current limitations when they try to debug non-debug builds.

There is a big disconnect between all the stuff compilers shovel into DWARF information and then what parts of that gdb is actually making active use of or even supports to begin with.

DWARF is the perfect case for why it's often better to just have an intertwined compiler & debugger implementation and information format instead of the current tragedy.

Generally when you see <optimized out> it really is because the compiler didn't emit location entry for that variable at that point in the program. There's plenty of stuff in DWARF that gdb/etc doesn't make a lot of use of but variable locations aren't among them.

there is a proposal recently in the LLVM community trying to use "extended lifetime" to solve this problem

Reply on news.ycombinator.com