Comment by amluto
2 days ago
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.
I don't see how this happens in a C++ function, since breakpoint() is not noreturn you'd have to be doing something very strange for the next instruction to be outside the function. It's possible some debuggers will show the next line, and even then that seems like a debugger QoL issue that's fixable pretty mechanically. A soft breakpoint can come from CD 3 or CC, even if you don't get the instruction length from the CPU there aren't that many possibilities. I'm sure we don't need everyone to start inserting extra NOPs to get the desired behavior.
If a function is inlined, the breakpoint can be at the end.
If you write:
Then there two obvious ways for code to be generated, one of which puts the address after int3 in the wrong basic block.
In a good enough debugger insn length might not matter - there will be a choice of addresses, ask all belonging to the next instruction. Subtracting one and handling the case where the address is in the middle of an instruction should be good enough.
(Or just track whether the address in question is the start or end of the insn. Keep in mind that, in basically every architecture, call saves the next address, not its own.)
Agreed, and just to make it shorter and clearer; when you resume a debugger, it resumes at that next address. If it's outside a basic block, it's because in the absence of a debug break, it was about to go off the rails anyway, nothing to do with the break.
...there is no bloody way debuggers don't just subtract 1 from the EIP on INT 3. Like... there is no way. Right?
If every single SIGTRAP was caused by an INT3 instruction, then this would work, but SIGTRAP can also be generated by single stepping where subtracting 1 would be incorrect.
GDB already compensates for breakpoints it inserts itself because it knows their locations, so it subtracts 1 as you suggest. It could also recognize embedded INT3 instructions but that requires distinguishing their traps from other causes of SIGTRAP which is much more complicated. So instead GDB generally leaves the instruction pointer unchanged for embedded INT3 instructions.
Here's a discussion of precisely this issue from the GDB developers:
https://sourceware.org/pipermail/gdb/2009-February/034621.ht...
An INT 3 isn't even always one byte; there's a one byte encoding, but I believe it's also legal to issue a two byte encoded INT N, where N is 3.
I’m pretty sure that even kernels from the date of that message report the trap/fault vector.
But let’s be clear. ptrace() is unbelievably crappy, and gdb is approximately as crappy.
I've been working in C++ using VS for about 15 years and for as long as I've remembered my heuristic has been that if I get a breakpoint the offending instruction is on the line above what was reported.
That's just an eternally confusing bug of VS/cdb. On other IDEs such as QtCreator with clang or gdb it shows the break red dot exactly where the issue is.
Obscure knowledge. I wanted to see how well our LLM overlords would detect this circumstance but without proper prompting, it was happy with "just generate int3"