Comment by tux3

2 days ago

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.

2 comments

tux3

Reply
amluto  2 days ago

If a function is inlined, the breakpoint can be at the end.

If you write:

    if (a)
        breakpoint();
    
    other code;

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

dwattttt  2 days ago

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.