3 ms·

I don't know what gdb does, but even on x86 a conditional breakpoint can be ridiculously slow. On a loop that executes a few hundred thousand times before meeti

by derf_ 11y ago

I don't know what gdb does, but even on x86 a conditional breakpoint can be ridiculously slow. On a loop that executes a few hundred thousand times before meeting the condition, it can take minutes to evaluate something that executed instantly before. I often go back, edit the code to add something like if (condition) { foo = foo; } recompile, restart the debugger, and break on the foo = foo line. Even with all of those steps, that's still faster than using a conditional breakpoint most of the time.

revelation 11y ago
For next time, Windows has the DebugBreak function which will stop the program and (if you have a debugger attached) act the same way as stopping on that line. On Linux, I've seen some people use asm("int 3") (which is what a debugger would use for software breakpoints).
comex 11y ago
Incidentally, GDB can sometimes evaluate breakpoint conditions on the target: https://sourceware.org/gdb/onlinedocs/gdb/Conditions.html https://sourceware.org/gdb/onlinedocs/gdb/Conditions.html (search for "target's side") I don't know what targets support it, though. (Pretty sure OS X isn't one of them.)
spc476 11y ago
Worse case scenario---the CPU only supports a breakpoint instruction. Doing a conditional breakpoint involves the debugger setting a breakpoint instruction at the next instruction, resuming, then resetting the breakpoint and setting a breakpoint at the next instruction (with special care taken for calls, jumps and conditional jumps) and doing this, for every instruction until the condition is met. Second worst case---the CPU has both breakpoints and single stepping mode (the 8086 supports this). In this case, the debugger no longer needs to set a breakpoint on every instruction, but the CPU still endures an interrupt per instruction until the condition is met. Best case---the CPU has a way to specify a condition in hardware (the 80386 and above can do this to varying degrees) but often you have a limited number of conditions that can be handled and if you exceed this, then you either have to disallow it, or fall back to one of the previous methods (or, perhaps depending upon the condition, you can play around with page settings to capture reads or writes but that has its own overhead).

by derf_ 11y ago

revelation 11y ago

For next time, Windows has the DebugBreak function which will stop the program and (if you have a debugger attached) act the same way as stopping on that line. On Linux, I've seen some people use asm("int 3") (which is what a debugger would use for software breakpoints).

comex 11y ago

Incidentally, GDB can sometimes evaluate breakpoint conditions on the target: https://sourceware.org/gdb/onlinedocs/gdb/Conditions.html https://sourceware.org/gdb/onlinedocs/gdb/Conditions.html (search for "target's side") I don't know what targets support it, though. (Pretty sure OS X isn't one of them.)

spc476 11y ago

Worse case scenario---the CPU only supports a breakpoint instruction. Doing a conditional breakpoint involves the debugger setting a breakpoint instruction at the next instruction, resuming, then resetting the breakpoint and setting a breakpoint at the next instruction (with special care taken for calls, jumps and conditional jumps) and doing this, for every instruction until the condition is met. Second worst case---the CPU has both breakpoints and single stepping mode (the 8086 supports this). In this case, the debugger no longer needs to set a breakpoint on every instruction, but the CPU still endures an interrupt per instruction until the condition is met. Best case---the CPU has a way to specify a condition in hardware (the 80386 and above can do this to varying degrees) but often you have a limited number of conditions that can be handled and if you exceed this, then you either have to disallow it, or fall back to one of the previous methods (or, perhaps depending upon the condition, you can play around with page settings to capture reads or writes but that has its own overhead).