How to build highly-debuggable C++ binaries

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 ]