Comment by amluto | Hacker News Reader

Comment by amluto | Hacker News Reader

    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.

(author) I have fixed this in the article and credited you in a footnote, thanks!

Doesn't gdb allow breakpoints to be made to be conditional?

Add a breakpoint somewhere in the code, say added as breakpoint #2. Then;

    condition 2 (x_id == 153827)

Or is there some other reason to not do this?

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.

If the CPU doesn't support conditional hardware breakpoints, some do.

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.

The rationale is explained in the article; it's for speed.

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.)

Reply on news.ycombinator.com