> On x86 it inserts an int3 instruction, which fires an interrupt, trapping in the attached debugger, or otherwise abnormally terminating the program. Because i

> On x86 it inserts an int3 instruction, which fires an interrupt, trapping in the attached debugger, or otherwise abnormally terminating the program. Because it’s an interrupt, it’s expected that the program might continue. In x86 lingo, it’s a trap, and calling it an interrupt misses the point. int3 is a “software interrupt,” but the vector 3 is universally configured by kernels as a “trap” (by setting the appropriate mode in the IDT). So the instruction completes, IP is incremented, and the kernel is notified. FRED tidies this all up. The kernel is notified that the event occurred and is given the length of the offending instruction. > However, regardless of how you get an int3 in your program, GDB does not currently understand it. GDB can’t really do better. If you have: jnz 1f int3 1: [non-error case here] Then all gdb knows is that IP points to 1. The issue may not be as bad with the int3 out of line: jnz 2f 1: [non-error case here] 2: int3 jmp 1b <— GDB sees this Then at least GDB knows what’s up. But that jmp may be omitted if gcc thinks that the instruction after int3 is unreachable. Maybe a future FRED-requiring debug API could report the address of the offending int3 and GDB could use it. But ptrace is awful, gdb is awful, and I’m not convinced this will happen.