Per VognsenSource-Level Debugging of Compiler-Optimised Code: Ill-Posed, but Not Impossible, https://dl.acm.org/doi/10.1145/3689492.3690047. There's almost no research in this area so it's good to see someone thinking about some of the challenges. I'd like to have seen a discussion of undefined behavior, specifically, since there's a paradox where C programmers are most likely to use debuggers exactly in cases where UB is present, which poses fundamental challenges to source-level debugging.
zwarich@pervognsen When writing C/C++, I mostly find myself using a debugger when things go wrong and I'm likely in UB territory. At this point, I'm mostly looking at the disassembly and all of the source/variable mapping of the debugger is a mere convenience, and it's understandable why some things don't work.
When I see people (mostly from or inspired by the Windows gamedev world) talk about continuous usage of debuggers, I do wonder a bit what they're doing with it. Is it a nice interface for getting traces of execution? Do they just want to set a breakpoint in a function for an input doing something they don't understand then step through it until they do understand? Do they actually want to execute newly compiled code from the debugger like a REPL?
Radek Jurga