Breakpoints in "unrolled loop"

I don't see why that should pose any particular problem. Debug information is usually stored as a function of binary location, i.e. you give it a binary location, and it looks up the source location from that.

It's usually the *opposite* case that causes troubles, i.e. when code folding has turned multiple copies of the same functionality into a single instance. Debuggers tend to behave very confusingly in such cases, jumping to what look like totally unrelated pieces of source code that just happen to expand to the same binary code. E.g. as you're stepping through one function, and nearing its end, it'll beam you straight to another function, possibly in another source file, that just happens to end in the same code sequence.

Ultimately, ease of debugging and optimal code are contradicting goals. The better you get at the latter, the worse you'll fare on the former.

if you select a source statement to set a breakpoint, the debugger has to select which binary location(s) get a breakpoint.

In single step, I would set the breakpoint at the next corresponding binary location. When setting a breakpoint during program execution (e.g. by background debug mode), I would set a breakpoint at _each_ corresponding location, since I can't know the PC at the time of breakpoint setting.

This can be impossible with massively unrolled loops and/or limited hardware breakpoints.

ack, that's indeed hard.

Oliver

Not quite true. Somebody has to make that decision, but it doesn't have to be done by the tool alone. I've seen at least one debugger offer a complete selection of eligible code addresses in such cases.

Similar problems can happen even without optimization, too. E.g. imagine setting a breakpoint on a statement that's actually a call to a multi-statement inlined function, or function-like macro.

Personally I think I'd prefer a tool that sets a breakpoint on the first copy in this case (assuming that it's really just an unrolled loop) or generally on the entry point into the unrolled portion.

Ultimately, source code binary code is an n:m relation. Yes, that makes it tricky to resolve queries in both directions. But I don't believe anybody ever promised that writing good debuggers for optimizing compilers was simple.

This would be fine. Do you remember which debugger did so?

Indeed. Currently, I have to accept to get a breakpoint on the first statement.

If there are function calls with long (potential) duration in the loop, this could delay the breakpoint hit. On the other hand, such loops shouldn't be unrolled.

No, but I try to forward some information to the supplier to make it better.

Thanks for your comments!

Oliver

ACCEMIC MDE, a debugger for Fujitsu 16-bit and 32-bit controllers.

But only for as long as the whole unrolled loop takes to return to its beginning. Unless that loop covers the majority of program execution time, odds are the code will be *outside* the loop the moment the breakpoint is set.