FpDebug breakpoint on "begin"

[Martin_fr]

One thing I wonder: in Lazarus, blue dots appear in the editor gutter when debugging is started. They disappear when debugging is finished. In Delphi, blue dots appear after compilation/build is completed and remain after debugging is completed. What is the reason for this difference in the behavior of both IDEs?

I don't know how Delphi implements them.
If they are loaded from debug info, or if the Delphi compiler creates dedicated info for the IDE.  (Like fpc could (for other purposes) with "-b" generate info for an IDE)).


In Lazarus, they come from the debug info. Without this, this, the IDE can not find out which source lines did generate machine code. (also that means, strictly speaking where fpc associates it, as sometimes fpc moves this when optimizing...).
So historically, Lazarus got them using GDB, and that only happened when the debugger started.
FpDebug too, only loads them when it starts debugging.

Though having a build in reader, the IDE could read that info at an earlier point. That raises the same question as keeping them after debugging does => what for?

As soon as you edit, there is a chance that they become inaccurate. That is true even during debugging, but usually with more extensive editing being done while the debugger does not run, the issue gets more noticeable.
If you break a line into 2, and then join each part with other lines (that may or may not have been added after the last compilation) then the blue dots aren't very accurate any more.

Also as for seeing if IFDEFed code is active, the Lazarus IDE highlights that without the need of compiling. The only part it wont show you is dead code elimination.  "if false then".


The only case were loading them after compile would be needed is, if you set your project to "not compile automatically". So you can
- compile
- edit
- run/debug without compiling the recent edits

Then of course you want the blue dots after compile, because they secretly contain the mapping of any changed line numbers due to edit after the compile (which helps setting breakpoints).
(Afaik delphi does not map line numbers for edited code ?)

Anyway, I also think of the blue dots as a nice indicator that the debugger is running. So thats a point for the current behaviour.

[Martin_fr]

I compared the location of the blue dots in Delphi and Lazarus. In Delphi, dots are placed near the left edge of the gutter. When debugging, they usually do not conflict with other icons. The dots in Lazarus are placed at the right edge of the gutter. As a result, they are often covered by other icons. Maybe it would be possible to separate vertical areas (stripes) in the gutter in which different types of icons would be displayed, so that they would not overlap? Additionally, divided into editor modes: editing and debugging. In each of these modes, the editor could display different icons in separate areas of the gutter.

Left vs right isn't the issue, or is it. Just were each type of icon goes compared to others.

Bookmarks go into the 1st (leftmost) column.
All the rest goes into the 2nd column => well, that changed: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40914

Even in Delphi, afaik breakpoints themself cover the blue dot.

So, this is only about error/warning/note icons?
They could be moved to the bookmark column (unless a bookmark is also set on that line).

I don't know if they would benefit much from having a dedicated 3rd column.

Btw, you can set the gutter to provide 3 columns (editor options > display / 3.99). But that wont dedicate any of the columns to anything.

[VisualLab]

As soon as you edit, there is a chance that they become inaccurate. That is true even during debugging, but usually with more extensive editing being done while the debugger does not run, the issue gets more noticeable.
If you break a line into 2, and then join each part with other lines (that may or may not have been added after the last compilation) then the blue dots aren't very accurate any more.

I think someone mentioned this on the forum before. In any case, this is supposed to inform the programmer which lines of code are being compiled (converted to machine code). I found this description in the Delphi documentation:

http://docwiki.embarcadero.com/RADStudio/Alexandria/en/Setting_and_Modifying_Breakpoints

Attempting to edit the code causes the blue dots to disappear from the Delphi editor's gutter (I just checked). All you need to do is position the cursor and press the ENTER key.

But from time to time there are errors in the position (vertical) of these dots. Here is one description of this problem:

https://ideasawakened.com/post/rad-studio-10-4-2-is-now-available-with-possible-cure-for-the-blue-dot-problem

It seems that in Delphi this information is generated at compile time and displayed after the process is completed.

Also as for seeing if IFDEFed code is active, the Lazarus IDE highlights that without the need of compiling. The only part it wont show you is dead code elimination.  "if false then".

Yes, it works fine.

[Martin_fr]

In any case, this is supposed to inform the programmer which lines of code are being compiled (converted to machine code). I found this description in the Delphi documentation:

http://docwiki.embarcadero.com/RADStudio/Alexandria/en/Setting_and_Modifying_Breakpoints

Attempting to edit the code causes the blue dots to disappear from the Delphi editor's gutter (I just checked). All you need to do is position the cursor and press the ENTER key.

During a debugging session, any line of code that is eligible for a breakpoint is marked with a blue dot Blue dot in the left gutter of the Code Editor.

So it is for debugging. Yes, you can set breakpoints before starting the debugger. But you can set them even before compiling.

For solving "where to set my breakpoint, so that it will work", it is better to make sure breakpoints on non-code line will break at the next line (within reasonable limits and conditions).

Personally I don't see an advantage to load the blue dots at an earlier point. Especially if you compile, without running, then the very next think that is likely done, is that you keep editing. So the dots would immediately be removed again.
But very well, ok, maybe someone has a workflow in which they do matter....

The other issue is that even if it were implemented, it then needs a debug info reader for each file format. Compiling for remote debugging, and that might be in gdb, and gdb only => meaning you have to initialize gdb as if you want to debug, just to read the dots.
And code needs to remember that it was loaded pre-debugging, so it can be cleared at an appropriate time.
And on option (though that is simple), because I definitely see them as indicator that the debugger is running.
....

Personally, I would need to be convinced that there is a huge benefit to it, before even considering accepting a patch for it.

[440bx]

Personally I don't see an advantage to load the blue dots at an earlier point.

I think having the blue dots be indicators that a.) the compiler generated code for that line of Pascal and b.) that the debugger is active is their most logical use.  I think that's pretty much what you're saying and, if that's the case, I obviously agree.

IMO, having the blue dots at any other time is just too error prone and actually confusing since it is no longer clear what they truly represent.

If the debugger isn't running then the programmer should simply presume that a source line of code is a place where the debugger can break.  That's not always the case but, the debugger cannot inform the user of that if it's not running.  Once running, the blue dots tell the true story.

As I was typing this, a thought crossed my mind (note: this not a feature request, just thinking out loud), in theory the compiler could always generate an instruction for every line of Pascal source.  For instance, if needed it could generate a noop for a particular source line (say a "begin", preferably at the very end of the "begin" prologue) and put a symbol in the debug tables for the debugger to use.  Optimization level: "minus 1" <chuckle>

[Martin_fr]

OK, so if you set a breakpoint on a "non blue dot" line, FpDebug can now stop at the next line. (depending on settings).

"next line" is the most logical choice, since that is right after the breakpoint gets passed.

Please note, if compiled with -O1 or above:

Code: Pascal  [Select][+][-]

1. if foo then
2.   exit; // or break / continue ...

the "exit" line may not have code.
In that case "next line" wont be reached (or well, it will, but only if exit is not executed), as the code takes a different path.
However, there is no way to solve that in the debugger or IDE. If exit has no (identifiable) code to break on, then it can't be done. (Compile with -O- instead)

There is a setting "BreakpointSearchMaxLines" (default 3)
- set to 0 means breakpoints will only be on the exact line.
- set to 1..25 will mean to look up to that many lines below.

The 1..25 has one exception => if the breakpoint is outside the function (defined as by above the first line for which fpc provided debug info), then only ONE line below will be checked. That prevents for example that breakpoints that are meant for the previous procedure (but are below it) will be attributed to the next.

Most functions will have code on the functions "begin" line => and usually breakpoint in front of that are rare.

Please test.


Note, that I also improved/fixed the ability to have multiply breakpoints hit. That was already possible for Watchpoint + breakpoint, or for address/asm break and source-break.

But now, you can also have several breakpoints stacked above one line. (And each can have actions, conditions, disabled, hitcount, ...)

[440bx]

Please test.

What follows is from a rather quick test.

The "break on next blue dot line" seems to be working fine.

Please refer to the screenshot.  The breakpoint is placed on line 3456 for which there is no blue dot, i.e, no code, and the debugger correctly and as expected, broke on line 3460 which is the next line where there are instructions.

One thought crossed my mind, when the breakpoint is set, the debugger doesn't know that the line has no code but, once the program is running and the breakpoint acts upon line 3460 instead of 3456, it would be nice if the debugger would reset the line number to the line number where the breakpoint occurred.

IOW, initially the breakpoint would display line 3456 as where it is set but, after the breakpoint is triggered and noticing that it didn't trigger on the line it is set on, then it should automatically (possibly user-setting controlled) reset the line number to the line number where it actually happened.  This would cause the breakpoint visual indicator (in the screenshot, a red line and red dot) to move to the actual line (instead of remaining on the "end" line.)    This doesn't rise to the level of "feature request" but, I think it would be a nice "polishing" touch.


ETA:

Added: reset the line number

[440bx]

I forgot to mention in the previous post... setting a breakpoint where there is a hint causes the hint to move out of the way   great stuff... the breakpoint is (at least to me) way more important than the hint.

[Martin_fr]

One thought crossed my mind, when the breakpoint is set, the debugger doesn't know that the line has no code but, once the program is running and the breakpoint acts upon line 3460 instead of 3456, it would be nice if the debugger would reset the line number to the line number where the breakpoint occurred.

IOW, initially the breakpoint would display line 3456 as where it is set but, after the breakpoint is triggered and noticing that it didn't trigger on the line it is set on, then it should automatically (possibly user-setting controlled) reset the line number to the line number where it actually happened.  This would cause the breakpoint visual indicator (in the screenshot, a red line and red dot) to move to the actual line (instead of remaining on the "end" line.)

Not by default. Imagine you temp commented a line (or IFDEF). Now you break on the next. And if you uncomment, all is back to what it was.

But if the breakpoint moved, that does not work. It will be permanently moved.

About manually adjusting the breakpoint location:
- Currently that can be done by editing the line number in the break properties.
- On my todo list: drag and drop of breakpoints. (and imho that would make it easy enough)

[Martin_fr]

I forgot to mention in the previous post... setting a breakpoint where there is a hint causes the hint to move out of the way   great stuff... the breakpoint is (at least to me) way more important than the hint.

If you mean, the hint moving into the place of the bookmark => yes.

If there is a bookmark a hint and a breakpoint => the order between breakpoint and hint may be partly random. I don't know what the current sort method is. But I have seen different ordering....

However, 3.99 will shrink those 3 and you still see them all.
There are still some hickups, like the current line indicator sometimes shows in the wrong column.... (I really opened Pandoras box... A lot of code just depended on only one column for all non bookmarks)

[Martin_fr]

Btw, 3.99   alt-mouse-click a breakpoint in the gutter (or to set a new breakpoint) => opens break properties. (for editing the line number and all else)

[440bx]

Alt-mouse click is a nice "shortcut" to set a breakpoint and adjust its properties.  Just tried and it's rather convenient.

About the hint icon moving... yes, that's what I meant.

Lastly, I see what you're saying about moving the breakpoint.  I hadn't thought about an "ifdef" being the cause of having no code on that line.  Moving the breakpoint in that case isn't desirable.

About the drag and drop of breakpoints, that would be a nice, very convenient feature.  Definitely welcome.

[Martin_fr]

I compared the location of the blue dots in Delphi and Lazarus. In Delphi, dots are placed near the left edge of the gutter. When debugging, they usually do not conflict with other icons. The dots in Lazarus are placed at the right edge of the gutter. As a result, they are often covered by other icons. Maybe it would be possible to separate vertical areas (stripes) in the gutter in which different types of icons would be displayed, so that they would not overlap? Additionally, divided into editor modes: editing and debugging. In each of these modes, the editor could display different icons in separate areas of the gutter.

Now warnings also default to the 1st column (2nd column, if you configured to show 3 columns). So the blue dots will be less often covered.

Of course, if you have several icons fighting for one column, then they will use the other columns.

Mind that if you join lines, and each of them has a bookmark before you join them, you can end up with multiple bookmarks on a single line.... (Same for breakpoints)