F8 - jump only to my code

[Nicole]

In Delphi there was an option, that the step F8 only stopped in the main unit.
Does this option exist in Lazarus?

[Martin_fr]

Is that when you use F8 to step from one paused line to the next line?

Or is that, when you use F8 before you even started the app?

The latter is not supported. (well it works with gdb, but will stop in the lpr / in the main "program MyApp begin ... end;" block).

If you use F8 while you are paused at one line, it should step over to the next line? That would (usually) be a line in the same unit (unless we talk specialized generics).

Well ok, if you are on the last line of a procedure. Then it steps out. That will be to the direct caller.
There is NO option to search for a caller in your code....

Or do you mean "step in" F7?

Here you can simply compile the LCL without debug info => and it wont step into the LCL any more...

If that does not cover your question => more details please.

[AlexTP]

The idea is: F8 stops only at the user app's code, not in LCL nor in other components.

[Martin_fr]

The idea is: F8 stops only at the user app's code, not in LCL nor in other components.

For now the only way is to change the settings for all those packages (and change "configure build lazarus" as many packages include those opts).
Of course that also affects what the stack window shows....

The idea of having certain units "prevented" by normal stepping is well known (and accepted as a "would be nice to have"). But it's on a long list, and not near the top.

The trouble I have with understanding this is, that I don't see where F8 is really affected by this?

F7, yes that I can see.

As I described: F8 does not enter another unit (except generics, and technically that is a matter of interpretation).
So as far as I know with F8 that never actually happens?

Maybe someone has an example?

Well, ok, it happens when F8 steps out.
But IF I use F8 on the end of "Form1.DoFormCreated" => then the code goes to the LCL. If F8 is not allowed to step to the LCL, then all it can do is
- open the asm window (and that would be worth)
- reject to step at all. (not much better)
- what else?

And otherwise, well example?


As for generics:

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

1. Unit MyCode;
2. type
3.   TFoo = specialize TFPGList<integer>;

TFPGList is in unit fgl.
But for TFoo the compiler creates a copy of the code in MyCode (maybe not all asm may will be copied, but some definitely will be / well copied with adaption for the specialized type)

Now if you are in any method of TFoo, the debugger could just keep showing that you are at the line "TFoo = specialize ..." => but that is crap.
So one can argue that since TFoo is in MyCode it should be stepped => and then the code in fgl would be selected...

Of course (if that feature existed) the implementation does not have to follow that view....

[jcmontherock]

In a similar way, how to avoid F8 from going to assembly part of instructions?

[Martin_fr]

In a similar way, how to avoid F8 from going to assembly part of instructions?

You mean when it hits an exception or run error?
Or are there other cases, where this happens?

Also, since you made your question explicitly about F8: Are there any cases where it happens with F8, but not with F7 or F9?
Or was the mention of F8 just an accident, and you meant the question for all cases of F7, F8 or F9?


There is no way to avoid the asm...
In some cases when this happens, it happens due to a bug.

1)
Check the stack window => if it does show (iirc limited to the top 30 entries) a stackframe that has sources => then the asm should not open at all.
Yet I know it does. It's a bug in that case.

2)
If the stack window does not show any entry with sources => then the IDE does have no source line to show.

It has 2 options (that I can think of)
- show the asm
- show a dialog: "The app stopped at an unknown location"

Would such a dialog really be better?

Mind, if you have an other idea what it could do, when it can not find out any source line ... well, please tell your idea.
But doing "nothing" is not an option. There must be some sort of info that the app paused.

Doing "nothing extra" could be an option, if an "app raised exception" dialog already gave the user the info....

In any case, if you are not aware: The IDE has an option to auto-close the asm window. If it pops open in the above case, and you continue with F9 (or anything that gets you back to sources) => the asm will be closed again.

[Thaddy]

In a similar way, how to avoid F8 from going to assembly part of instructions?

If you want to debug the compiler itself or one of the standard libraries you need no compile everything with debug information.
Then you get what you want, but for beginners or intermediates it is not that straightforward, but doable.

[Martin_fr]

If you want to debug the compiler itself or one of the standard libraries you need no compile everything with debug information.
Then you get what you want, but for beginners or intermediates it is not that straightforward, but doable.

In the context of the thread "stick to the users own (aka user-written) units only" (derived from the original post quote "the main unit"), and seeing no indication in jcmontherock's post that his post wasn't part of that context, how did we get to debugging - with full indent of the user - the RTL or FCL?

Or do you, @Thaddy, have information that he is indeed the author of any of those units? scnr.

[Martin_fr]

that the step F8 only stopped in the main unit.

Is that when you use F8 to step from one paused line to the next line?

Just been struck by an idea...
(Though, it may not be your issue, since you did not mention a faulty "step in" / see below)

You wouldn't by any chance (still) be using the gdb backend?

Tools > Option :: Debugger > Debugger Backend.
=> That really should say ... "[FpDebug internal Dwarf-debugger]"

If you are using the GDB backend:
GDB (or at least many versions of it, not sure if fixed in the meantime) has an issue. This is either within gdb, or in some form triggered by the way FPC provides debug info.

This issue means, that on "step over" (F8), the debugger would sometimes perform a "step in". And that could be a "step in" to code in the LCL/FCL/RTL or elsewhere....

The gdb backend has a workaround for this, but it isn't enabled by default, because there is no way to know if the selected version of gdb, in combination with the configured fpc, and for the selected platform/target is actually exposing the issue....
The workaround can be enabled in the "debugger backend" setting for gdb. It is in the property grid under the name "FixIncorrectStepOver".

However, I would really recommend not to use the gdb backend, if possible.
You should change to the FpDebug backend.

New Lazarus installations actually default to FpDebug. But in case of an upgrade, it can happen that the old config is kept. Then the upgrade to FpDebug must be done by the user themself.

[jcmontherock]

How do we do an update of fpDebug under Windows ?

[Martin_fr]

How do we do an update of fpDebug under Windows ?

Unless your issue is that pressing F8 for "step over" does a "step in" (as F7 would do), then FpDebug is not solving the asm-window issue. Not yet anyway.
But FpDebug is in many other ways a huge improvement.

As I said:

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

1. Tools > Option :: Debugger > Debugger Backend.

And on the top of the frame is a toolbar with a dropdown, and FpDebug should be in that drop down.

Attached image shows how it should look like.
- You should find FpDebug in the green drop-down
- You should not need to change the red field. (it will be set as shown, after you selected FpDebug in the green field)


A classical issue that currently brings up the asm Window is something like

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

1. var l: TStringList;
2. begin
3.   l := TStringList.create;
4.   l.add('item 1'); // now has 1 item
5.   writeln(l[99]); // TStringList will throw an exception, and the debugger does not show this line, but instead the asm

For this example, there is no fix.
(In fact, this very example FpDebug may currently do worse than Gdb)

[Nicole]

screenshoting  "posting including screenshot" to keep it in my records

thank you!

[Thaddy]

Or do you, @Thaddy, have information that he is indeed the author of any of those units? scnr.

No, I am only the author of a couple of 10'ths of accepted patches and a 25% contributor to KOL. And a noise, sometimes.
In this case, at least the rtl and packages need debug info. That can also be achieved, but the easy way out is to do it all.

[Martin_fr]

Or do you, @Thaddy, have information that he is indeed the author of any of those units? scnr.

No, I am only the author of a couple of 10'ths of accepted patches and a 25% contributor to KOL

You seem to have missed a tiny difference.... I underlined the important bits. "he is" was referring to "jcmontherock". (I do apologize so for having assigned a gender without knowing. It should either be "she/he" or "them")

[jcmontherock]

Thanks a lot Martin_fr I did what you suggest. So, debugging is clearly better. I do not have a lot of assembly codes debug.