Re: Breakpoints in "unrolled loop"

Oliver Betz wrote:

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

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.

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.

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

Relevant Pages

  • Re: Breakpoints in "unrolled loop"
    ... to select which binary locationget a breakpoint. ... I've seen at least one debugger offer a complete selection of eligible code addresses in such cases. ... copy in this case (assuming that it's really just an unrolled loop) or generally on the entry point into the unrolled portion. ... But only for as long as the whole unrolled loop takes to return to its beginning. ...
    (comp.arch.embedded)
  • Re: Breakpoints in "unrolled loop"
    ... to select which binary locationget a breakpoint. ... Do you remember which debugger did so? ... imagine setting a breakpoint on a statement that's actually a call to a ... loop, this could delay the breakpoint hit. ...
    (comp.arch.embedded)