Avoid system units debugging

[janasoft]

Good morning.
I think this must have already been discussed in the forum, but I can't find anything.
My problem is that when I debug, while stepping through the instructions, I end up entering the system's own units.
It happens with any application. With a simple program that has a button and writes text in a memo when the button is clicked, when I trace, I end up in button.inc, buttoncontrol.inc...
This didn't happen before. I suppose I have configured something incorrectly, but I don't know what I need to do to avoid it.
Thank you very much for your help.

[Zvoni]

Your Lazarus/FPC compiled with Debug-Info?
https://forum.lazarus.freepascal.org/index.php?topic=35826.0

[janasoft]

No. it's instaled from the downloaded file of the webpage.
I've build the IDE with default settings but I get the same behaviour.
Uninstalled 4.2 and installed 4.4 from scratch. I still see the system units: lazloggerbase, application.inc, fgl, etc.
Any idea?

[marcov]

I have the same problem.  I don't want to trace into handlers of relative basic units (system, objpas,sysutils, classes and some generics container units etc). Default I would want to be able to debug the more peripheral units (most of packages/)

I tried to build everything with debuginfo, and then strip those units, but that doesn't work. The debugcode of other units refers the debug code of the core units, and linking fails.

So I assume this needs to be handled in the debugger, to not enter units on some list.

Probably this is why Delphi has two complete trees of DCU (release/Debug) of everything.

[Martin_fr]

I've build the IDE with default settings but I get the same behaviour.
Uninstalled 4.2 and installed 4.4 from scratch. I still see the system units: lazloggerbase, application.inc, fgl, etc.
Any idea?

Default settings may include debugging for those units.

1) menu: Tools > Configure build lazarus
- Select a non debug profile
- make sure "custom options" does not contain any -g -gw -gl -gs ...

2) Open package LazUtils, Lcl, LclBase
Go to package options of each, and ensure under "debugging" that "generate debug info" is OFF

3) In your project "project options"
page "additions and overrides" => make sure you did not add overrides for those packages above
(most likely you have not / but just for completeness)

4) if you edited fpc.cfg => well then you would know you did ...

I have the same problem.  I don't want to trace into handlers of relative basic units (system, objpas,sysutils, classes and some generics container units etc). Default I would want to be able to debug the more peripheral units (most of packages/)

I tried to build everything with debuginfo, and then strip those units, but that doesn't work. The debugcode of other units refers the debug code of the core units, and linking fails.

Yes... to both/all.

1) Unlike LCL/LazUtils this cannot be separated that easily.

2) On linux debug info indeed refers cross unit / on window your approach would maybe work
you might try to run make for complier and rtl, without debug info. And then run make for packages only (and have debug info on). If package are build when the rtl .o / .ppu don't have the debug info, then they should likely not refer to it....
Though: NOT TESTED

Or maybe you can strip just line info, but not the other debug info.... (not sure if that would be enough)
Not sure how....
But strip (or was it objcopy) has some options... I noticed that when I saw the compiler calling them to extract debug info for "external debug info"

3) Yes, the debugger will eventually need "exclusion lists" for "step in" => those can be based on unit names and function names.
But that will be a while...

However, if you do step into any such routine you can
- Immediately Step out / shift F8
That will bring you back INTO the calling line (not after).

=> That means
  self.CallVirtualFoo;

- F7: Will step into _FPC_...object_check...
- Shift F8 (step out) returns to that line
- F7 (again) will now step into the CallVirtualFoo
Well, if there are other _fpc_check.... then you have to repeat that...

[marcov]

2) On linux debug info indeed refers cross unit / on window your approach would maybe work

This was on Windows, with -gw2 -godwarfsets

you might try to run make for complier and rtl, without debug info. And then run make for packages only (and have debug info on). If package are build when the rtl .o / .ppu don't have the debug info, then they should likely not refer to it....
Though: NOT TESTED

Yes. Something like that. But rtl-objpas/vcl-compat/rtl-generics is in packages.

Or maybe you can strip just line info, but not the other debug info.... (not sure if that would be enough)

Will that prevent tracing in to procedures?

3) Yes, the debugger will eventually need "exclusion lists" for "step in" => those can be based on unit names and function names.
But that will be a while...

As long you understand it is currently my primary wish (and I assume of others too). Even if we have a "multiple trees" like solution like Lazarus that is still inconvenient for people tracking trunk like me.

However, if you do step into any such routine you can
- Immediately Step out / shift F8

That is a good tip, I'll try that.

[Martin_fr]

Or maybe you can strip just line info, but not the other debug info.... (not sure if that would be enough)

Will that prevent tracing in to procedures?

Not 100% sure. Probably.

When the debugger encounters a call (in a step action), it always steps in. Because it needs to know where it goes.
It then checks if the code has debug info, if not it steps out again. (well after jump pad  checks for interfaces)

"debug info" in this contexs IIRC would be line info.

Though of course there is also the info for the entire procedures address range... I don't recall that this would be used in this context, but... not 100% sure.

[janasoft]

Please, keep in mind that I'm starting from a clean installation

1) menu: Tools > Configure build lazarus
- Select a non debug profile
- make sure "custom options" does not contain any -g -gw -gl -gs ...

Normal IDE: no options
Debug IDE: -gw3 -gl -gh -gt -Co -Cr -Ci -Sa
Optimized IDE
Clean Up + Build All: no options

2) Open package LazUtils, Lcl, LclBase
Go to package options of each, and ensure under "debugging" that "generate debug info" is OFF

I don't know if you are referring to this. All Packages has this options

3) In your project "project options"
page "additions and overrides" => make sure you did not add overrides for those packages above
(most likely you have not / but just for completeness)

Nothing added

4) if you edited fpc.cfg => well then you would know you did ...

Not touched. I didn't even know it existed 

However, if you do step into any such routine you can
- Immediately Step out / shift F8
That will bring you back INTO the calling line (not after).

This is useful. At least it saves a few steps.

[Martin_fr]

Well, you image shows the setting is ON => switch it off.

If you build the package LazUtils with "Generate debug info..." OFF => then it shouldn't step into it anymore .

And as profile, use "Normal IDE" or "Optimized IDE"

[janasoft]

I modified the check for two packages, and this has resolved the problem for the units of those packages.
That said, I don't think it is very appropriate to have this option checked by default  for the 64 packages that make up the IDE.
In my opinion, it would be more appropriate for it to be unchecked by default, allowing each user to enable the ones they need based on their requirements.
Regards

[Martin_fr]

I don't know what the decision behind that is/was. It's probably been a long time ago...
Feel free to add a feature request on the bug tracker. Maybe someone knows.

It also would need to change the installer, since all of those packages units are pre-compiled. So if you don't change those settings, then you can compile your project without needing them build.


There are ways to disable them quicker.

1) Most of the packages include the IDE build option (its in the "custom options": $(IDEBuildOptions) )
Those that do, will follow changes in the "configure build lazarus" dialog. So you can add there:
-g-
The trailing - acts as an off switch.

2) Per project
In the project options is "additions and overrides" It acts on all packages and projects. (but must be done for each project).
https://wiki.freepascal.org/IDE_Window:_Compiler_Options#Targets_of_build_options
You can also give the -g-
But then that affects the project too, so you need to configure it to exclude the project.

[janasoft]

Many thanks for your answer and commnents Martin_fr.
Like you say this behavior has been occurring for several versions
I've opened an issue in bug tracker. Perhaps someone has an explanation