C++26: The New Debugging Header

amluto

Sadly the PR gets a detail wrong: > Implementations are expected to optimize the code generated to be as minimal as possible for the platform. For example, on X86 it’s expected that this produces a single INT3 instruction. The goal in this expectation is to place the debugger as close as possible in the caller of breakpoint() to improve the debugging experience for users. This is the wrong design on x86 at least with many debuggers. x86’s int3 is a trap and reports the address of the next instruction in the saved register state [0]. Most debuggers are not very clever and just use the saved address to generate the offending line of code and the call stack. But if the trap sequence is just int3, then the saved address could be outside the offending basic block or even outside the function entirely. gdb is certainly in the class of debuggers that get this wrong. The easy workaround is to generate int3; nop for the breakpoint instead of just int3. The saved address will point to the nop and the debugger will be happy. [0] FRED also reports the instruction length, allowing one to deduce the trapping address.

singron

Pangram says the last 2/3rds are AI generated. I suspected when I got to this line: > The separation of concerns is deliberate — breakpoint() and is_debugger_present() are orthogonal building blocks, and breakpoint_if_debugging() is the convenience composition. It might be a false positive or just a few spots. Or maybe it's rage bait. I'm sorry if the author actually writes with this style.

dataflow

Anybody know how MSVC plans to implement this, given their __forceinline still doesn't inline in debug mode?

eklitzke

In the almost never cases I've had to do this I write `raise(SIGTRAP)`, portable to all Unixes.

1over137

I wish the C and C++ standards people would go through open source code out there and standardize all the platform-specific things like this case here.