How to build highly-debuggable C++ binaries

Re:How to build highly-debuggable C++ binaries by amluto on Monday July 29, 2024 @07:40PM (#41104749)

    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.

[ Parent | on HN ]

Re:How to build highly-debuggable C++ binaries by cordenr on Tuesday July 30, 2024 @02:53AM (#41106646)

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?

[ Parent | on HN ]

Re:How to build highly-debuggable C++ binaries by pjmlp on Tuesday July 30, 2024 @03:41AM (#41106917)

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.

[ Parent | on HN ]

Re:How to build highly-debuggable C++ binaries by flohofwoe on Tuesday July 30, 2024 @02:56AM (#41106673)

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.

[ Parent | on HN ]

Re:How to build highly-debuggable C++ binaries by pjmlp on Tuesday July 30, 2024 @03:42AM (#41106918)

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

[ Parent | on HN ]

Re:How to build highly-debuggable C++ binaries by mgaunard on Tuesday July 30, 2024 @04:44AM (#41107231)

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

[ Parent | on HN ]

Re:How to build highly-debuggable C++ binaries by kazinator on Tuesday July 30, 2024 @10:16AM (#41109430)

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.

[ Parent | on HN ]

Re:How to build highly-debuggable C++ binaries by kazinator on Tuesday July 30, 2024 @10:15AM (#41109411)

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

[ Parent | on HN ]

Re:How to build highly-debuggable C++ binaries by dhashe on Wednesday July 31, 2024 @06:15PM (#41124064)

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

[ Parent | on HN ]