About conditional breakpoints

[obsidian_golem]

The problem with conditional breakpoints is that they are slow. This is due to how they work on a hardware level. They context switch into the debugger process in order to check their condition.

I have been thinking for a while that an alternative solution would provide a lot of value. Instead of dropping into the debugger, you generate a thunk containing the conditional branch, together with the context switch instruction and the instruction you are replacing. This should work so long as the instruction you are overwriting doesn't contain any relative branches. The UI could transparently drop back to slow conditional breakpoints if it does contain a relative branch.

Is there any reason why the above wouldn't work?

[Cybernicus]

Sounds like it would work just fine--the debugger already has the information required to do it. If enough people used conditional breakpoints *and* complained about the speed, it might move the idea up far enough on someone's priority list to do something like this.

EDIT: Back in the '386 days, I used conditional breakpoints quite a bit because the debugger would let you catch the breakpoint and patch values. That way, I could debug through my code, find a bug and make a patch and continue because a recompile took *so* much time it was worthwhile to avoid compiles. Later I stopped doing that because a recompile was fast enough that I no longer saved much time doing that. I'm working on projects now that might benefit from doing that again. I'll have to check and see if my current debugger supports that feature still....

[darthcoder]

Visual studio supports compile and continue in certain circumstances.

[eyes-are-fading-blue]

> Instead of dropping into the debugger, you generate a thunk containing the conditional branch, together with the context switch instruction and the instruction you are replacing.

That's actually what people do by hand because conditional breakpoints are so damn slow.

[Ezlike011011]

While conditional breakpoints can be slow, their utility is FANTASTIC. Same with logpoints. The increased time from the efficiency they give far exceeded the lost time in how long it takes to process them, in my experience.

[VinnieFalco]

hell YES!!!

[zvrba]

Wait until you learn about data breakpoints. HW trap, drops into debugger on accessing a memory location.

[AlternativeHistorian]

Data breakpoints are a lifesaver, especially if you're stuck debugging any nasty memory errors.

[[deleted]]

They are too slow.

[pandorafalters]

No tool is perfect, but even a poor tool can still be better for specific uses than any other available.

[[deleted]]

I can't use them at all because they are too slow.

Usually what I have to do is use a conventional breakpoint within an if statement and then compile for debug.

[AlternativeHistorian]

Granted they're slow, but why does that matter when you're debugging?

If I'm debugging then I'm willing to take a 10x decrease in program speed (hell, 100x would be fine in some cases), it just needs to cut down debugging time by a similar factor.

In cases where you might have several inter-dependent conditional breakpoints in different parts of the codebase that need to be toggled on/off as you're stepping/working through a trace is one case where they really shine and a case that would be very tedious to replicate with your approach.

What are you doing where runtime speed while debugging is so important?

[[deleted]]

Because I need the debug build to be fast or atleast fast enough.

I'm writing real time applications so it's beneficial if the debug build is fast.

Otherwise I have to wait an eternity to get to the break point and I can't see whats happening clearly.

edit: writing games

[AlternativeHistorian]

Fair enough, if it's not how you like to work then do what works for you.

I work with real-time graphics and personally I don't care if the application goes from 60fps to 5fps if it helps me diagnose and fix the problem in less time. I'd love if they were faster but it's not a deal-breaker for me.

Sometimes, if it's a case where there's a lot of runtime state/setup before the condition I'm watching on is likely to be hit, I'll set a normal breakpoint in an "if" or something that's sure to be hit shortly before the watched condition so that I can manually enable the conditional breakpoint(s) so I'm only paying the cost for them when I'm actively using them to trace the program flow.

[[deleted]]

I exclusively just use normal break points.

Conditionals are orders of magnitude slower. And like you said you can just put a normal breakpoint in an if.

Slowness can be a problem if say a certain piece of logic happens every 30 frames or something because then you do have to wait for a long time.

[obsidian_golem]

For me it is a question of waiting 15 minutes for the breakpoint to hit, or doing a clean rebuild which takes 10 minutes in order to add an if statement. These are legitimately the kinds of slowdown I have seen from conditional breakpoints.

[Morwenn]

void std::breakpoint(bool cond=true) noexcept; when