[Explained] Breakpoint in a procedure

[Joanna from IRC]

Hello again..
I’ve always been curious why when I put a breakpoint at end of a procedure, the code goes straight to the breakpoint without executing any code then it goes to beginning of procedure. So it goes to break point at end twice. Why does it do this? 

[Martin_fr]

Well, FPC has a curious way of writing line info.  Though I haven't seen that particular order myself. But it may depend on OS, Fpc version, settings, ...

Usually (for me) entering a function works fine. But leaving goes "end, begin, end" sometimes even "end, begin, begin, end".

One issues is, that some procedures have hidden, internal "finally" blocks. And while they are executed at the end, fpc puts the line number of the begin there.
And the stepping from begin to begin => the finally is a sub procedure (at least on some OS), but the debugger hides that (or you could never "step over F8" when there is code in a finally block. So in the "begin begin" case the debugger steppend to the finally... (Ok that bit could be avoided by the debugger, but it would still go to the begin line, because FPC said that is what should be done).

Breakpoints have the same reason as stepping. A single line of code can generate multiple blocks of asm  (E.g. a specialized generic, that code may exist once for every different type for which it got specialized). A breakpoint set to such a line must catch it, never mind which asm block got entered by the CPU. If the compiler writes some of the "end" code with the begin line number, then the begin line number has several blocks => and the breakpoint catches for any of them.

I don't know an example for the end line containing "begin" code, but if it does then the same thing happens.


Then depending on the debugger ...

There is an issue where fpc writes line info incorrect and overlapping with code the end of the procedure before... This can also lead to strange stepping/breakpoints. For the last procedure in a unit, the code may jump to the first line in another unit.... And with gdb I have seen the debugged app crash, because the breakpoint went into the wrong place. Not sure if that issue still exists....

[440bx]

So it goes to break point at end twice. Why does it do this? 

As Martin mentioned it is determined by the debug line information emitted by the compiler.

if you want to see what the compiler did and what the debugger is following, simply open the assembly view.  In that window you'll see the line numbers emitted by the compiler the debugger is using.

That also explains why in some function calls that use multiple parameters, single stepping occasionally steps on individual parameters before entering the actual function.  It also shows the "with" statement often being responsible for back and forth jumps.

In general, the assembly view (View->Debug windows->assembler) often provides answers to behavior that seems unusual.

HTH.

[Joanna from IRC]

Thanks for the answers, I’m using the gdb and I’ve had it just stop working and make me halt program many times. Even after I set the optimization level to zero. For some procedures I try to trace and it opens assembler window and makes me trace through there for awhile which is no fun.

It is interesting that there could be hidden code in the procedure that I can’t see .

[Martin_fr]

Well you can use

Code: Text  [Select][+][-]

1. objdump --dwarf=decodedline

to see what line info there is.

[MarkMLl]

Thanks for the answers, I’m using the gdb and I’ve had it just stop working and make me halt program many times. Even after I set the optimization level to zero. For some procedures I try to trace and it opens assembler window and makes me trace through there for awhile which is no fun.

It is interesting that there could be hidden code in the procedure that I can’t see .

Much of it depends on whether you've got variables initialised at declaration or anything similar. Except, finally etc. blocks might cause this (and they unarguably insert a lot of "hidden" code, e.g. to free heap allocated for locally-defined strings). A particular case that you'll see is when stepping through a for-begin-end structure (i.e. there is more than one controlled statement), where it often appears to jump to the end and then nip back to assign a value to a local variable.

However I must warn that much of the behaviour will depend on the optimisation level: the less the optimisation the more predictably linear the execution sequence will be.

I don't generally have the problem of debug info only being displayed as assembler, possibly because I am in the habit of building both FPC and Lazarus myself and with lots of debugging enabled (and, for that matter, minimal optimisation).

The major situation in which I get lockups is if trying to debug an event, e.g. a menu click.

MarkMLl