if (breakpoint_1 && (x_id == 153827)) {
__asm("int $3");
}
No, don’t do it quite like that. Do:
__asm(“int3\n\tnop”);
int3 is a “trap”, so gdb sees IP set to the instruction after int3: it’s literally the correct address plus one. gdb’s core architecture code is, to be polite, not very enlightened, and gdb does not understand that int3 works this way. So gdb may generate an incorrect backtrace, and I’ve even caught gdb completely failing to generate a trace at all in some cases. By adding the nop, IP + 1 is still inside the inline asm statement, which is definitely in the same basic block and even on the same line, and gdb is much happier.
Only reason I can think of is that conditional breakpoints in the debugger can be much slower than compiling that same condition right into the debuggee.
The only reason is that many still don't learn how to use debuggers, people write blog posts about language featuritis, rewrite X in Y, and then keep using debuggers as if stuck in the 1960's.
grandparent is not advocating making it unconditional, but just adding the nop instruction to the __asm part.
Inserting an unconditional debug trap into a shipping, production executable, is a complete nonstarter. The program will receive a signal that is fatal, if unhandled.
On ARM targets, sometimes I've had to fiddle with the PC register in gdb to get a backtrace to work, like increment or decrement it by 4. (Not even related to using planted debug traps.)
