Who Is Debugging the Debuggers? Exposing Debug Bugs in Optimized Binaries
arxiv.org
arxiv.org
(gdb) p x
$3 = <value optimized out>
(gdb) p $ecx
$4 = 1234
I've long since grown accustomed to mentally decompiling the Asm and finding the correspondence to the source from that instead.
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.
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 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.
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.
I am one of the paper authors, the paper has been accepted for presentation at ASPLOS 2021.
If you have any question let me know!
We plan to use the framework to investigate more the correctness of debug information. Personally, I am not interested in startup and commercial opportunities.
Releasing the software is a step we are discussing.
Is there anybody working on evolving DWARF in the ways you suggest in the paper?
We are not working on DWARF. However, we hope that the paper will spur a public discussion on these problems. Helping the entire community to have a more expressive standard.
It'd be great to hunt those kinds of bugs, however it's hard to define what the "right" behaviour would be in those circumstances.
We are able to identify some kind of mis-stepping behaviour (look at Section 7-6). However, as you can imagine, we cannot catch all cases.
As you pointed out, a real problem is that there is no clear definition of what should be the semantic of debug information in the optimized binary (e.g., the compiler is free to squish several lines of source code into a smaller snippet of assembly language).
We are working to have more refined results in the near future .
For a second here I thought they had called their tool "\n". That would be pretty baller...
> Our framework feeds random source programs to the target toolchain and surgically compares the debugging behavior of their optimized/unoptimized binary variants.
I thought this had the flavour of John Regehr's work, and sure enough, they're using C-Reduce.
An interesting somewhat related paper about automatically exposing bugs in C compilers, by Regehr et al: Finding and Understanding Bugs in C Compilers, https://www.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf
edit I missed the author's comment in this thread that Releasing the software is a step we are discussing. Please do release the framework, ideally under a standard Free and Open Source licence. As we've just seen with C-Reduce, this is a helpful thing to do.
IME "Heisenbugs" are specifically bugs whose behavior changes when you attach a debugger (or other instrumentation). It's a joking reference to the Heisenberg uncertainty principle of quantum mechanics. The more you try to measure one property of the system, the less you can know about some other related property. They're usually race conditions or memory corruption where the instrumentation disrupts the timing or order of operations just enough to make the bug go away.