Broken debugging of generic codes

[PascalDragon]

Why do you expect that?
At that point, there is no code yet, generics are templates, code generators with a fill-in or two..
You can only debug such code once you have specialized it.

Such assumptions will also fail in e.g. C++.
There is no code for the debugger to debug.

If there is a specialization - which there is, namely in project1.Test - then the compiler will generate the debug information for the specialization with the locations of the generic. So the code as presented by Okoba is debuggable (at least with an older version of Lazarus; I used 3.0 😅 ).

Please also note that

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

1. type TFoo = object
2. procedure Bar;
3.  

requires fpc trunk to debug inside Bar (you can breakpoint there, but you will not see any fields of TFoo/self)

That also explains why I have problems debugging parts of FPC with recent Lazarus versions. 😅 Why did this work with GDB however? 🤔

[Martin_fr]

There are 2 issues in FpDebug, and in combination they break this.

If unit1 has a generic then
- there is a "Compilation Unit" for unit1 => with either no content, or any non-generic code
- there are line info in other "Compilation units" that have line for unit1 (when a specialization takes place in another unit)

Both is correct.

1)
FpDebug does sometimes decode the unit name as "unit1" and sometimes as "/foo/bar/unit1" => making it to different units.

2)
In some places it will search both. (And it may need to, if there are partial parts involved for some reason)
But in some places it will only search one list => and ignore the other => boom

Now I need to see how to fix that.
The issue is, that
- for units (as long as it is pascal) it is (currently / pre dottet unitnames)  save to ignore the path.
- for include files it is not. (that problem also already exist, in places where both lists are searched)

So basically, I don't want to fix one thing by breaking another.

To make matters worse main and fixes have different implementation, but need both to be fixed.

[Martin_fr]

And of course, to make thinks worse about full paths: Prebuild installs may have wrong paths.
Any installed ppu contains the (usually full) path of where it was build by the release builder. But that differs from where the sources are installed on the target system.

Which means to always look for any unit with the same filename (without path). Even though that has problems of its own.

[Okoba]

Can I ask why FpDebug do not use the full path all the time?
And why the issue I faced is happening? It is the same project in different paths, even with a bug, shouldn't act the same? Why folder name effects this?

[Martin_fr]

Can I ask why FpDebug do not use the full path all the time?

Because if you download the installer, then some files like the LCL are already build, and there debug info is already included. That debug info will have the path of where it was when it was build. But you may install it anywhere on your disk => so the full path in the debug info will be wrong. (mind that is the full path to where e.g. Forms.pas is, or was during the build).
Then again, in the past (without dottet namespaces) you could only have on "Unit forms" in your app. You can not have 2 units of the same name (include files are different ...)
But in any case to find that "forms.pas" the full path must be ignored. (it is also ignored when the IDE uses gdb)

Why is your unit1 twice in the project? / Why does it appear with/without path?

Well because a unit1.o is created with the code in unit1 (all code that can be compiled directly). Specializations aren't in there, because it would not even be known for which type they are needed, and the types may not yet even exist. (Think of fpc's FGL unit, that is in already compiled and installed).
When unit1 specializes the generic, more code is created, but can't be added to the original .o file (in case of fgl) => So in the debug info it is appended as xtra info for the unit2/fgl file.
So therefore the debug info has 2 entries for the same unit.
That one is loaded with and the other without path => that is a bug in fpdebug

And why the issue I faced is happening? It is the same project in different paths, even with a bug, shouldn't act the same? Why folder name effects this?

2nd paragraph above.

[Okoba]

Thank you.

About the second question, I have the same project in two paths: C:\test\ and C:\test2. Both has the same unit Unit1. Why the first raises the error but the second does not? What I understood is that you say that there are basically two unit1 debugs, unit1 and unit1/project1. But it should happen for the both projects and raise the same issue.

Sorry if I am asking an irrelevant question. I will be waiting to test any solution from you.

[Martin_fr]

Thank you.

About the second question, I have the same project in two paths: C:\test\ and C:\test2. Both has the same unit Unit1. Why the first raises the error but the second does not? What I understood is that you say that there are basically two unit1 debugs, unit1 and unit1/project1. But it should happen for the both projects and raise the same issue.

Sorry if I am asking an irrelevant question. I will be waiting to test any solution from you.

If that is the one to which you posted the "works" image earlier => in that image the "non-generic" function in unit2 did not have blue dots. So it did not work, the error just applied to other code.

Once the debugger has 2 entries for the same file, it uses only one of them => but, which one it uses may change. (haven't worked out all the detail for when it changes).

[Martin_fr]

So I found another related issue (which affected when the issue happens) https://gitlab.com/freepascal.org/fpc/source/-/issues/37658 https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/75c2186b1d45165b2b97c7facf986135811df436

However, as the bug states, it did not work before that either. Because the compiler also add wrong info (haven't checked if that changed since).

But the "fix" isn't right either. It may just by chance have worked for that specific case.

[Martin_fr]

OK, I think I have a fix for the the particular issue of this topic: https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/514157160898ed805b6c09ac4d18b14044ffea56

This was a type in the fix to the issue https://gitlab.com/freepascal.org/fpc/source/-/issues/37658
However, I have to do more tests.
Especially the linked issue may not be fully fixed by the workaround. Code from "generic.collections" (and possible fgl) may still not always be debug-able. But I need to revisit that, and do some more tests.

[Okoba]

Do you want me to check it or should I wait for future checks by you?

[Martin_fr]

You can (and please should) use/check it.

I tested it with your example, and it fixed it for me.


Also, while there may still be issues with generics from the RTL / LCL (if you use prebuild installs) they would likely have existed before that commit I just made.

If you did build your own RTL / LCL (e.g. using FpcUpDeluxe) then I it may (or may not) work better.
But there are many combinations. So I will have to do more tests.

[Martin_fr]

That also explains why I have problems debugging parts of FPC with recent Lazarus versions. 😅 Why did this work with GDB however? 🤔

I don't know all the internals of gdb. So especially I am not sure how the query for the blue dots works correctly in gdb.

But, when setting the breakpoint fails on full name, the IDE will always sent "just filename" to gdb. And (I expect) gdb will then check all files (whatever full/partial/none path they have) . So the breakpoint will get set, if there is any way to do so.

[Martin_fr]

Here is an additional patch, that may improve the debugging of generics.
https://gitlab.com/martin_frb/lazarus/-/commit/3e9e3af5e27fdc297b6346564e6ce58e8afbabc7

This is for cases, if the unit providing the generic is in a different folder (or package / eg compiled into ppu outside the compilation of the project).
I did some quick test, and it appears to work. I will have to do more tests.

If you can, I appreciate if you test it too.


If there are include files,
- where several include files have the same name (without path)
- have no source / or were pre-compiled by someone else (so the source is not in the expected place)

Then lines between those may be mixed.
This may (most likely) have happened already before. But it may have increased now.

However, this can not fully be avoided (or only at very high cost).

Since (even if the before linked fpc bug did not exist) the full filenames in the debug info may be incorrect, the debugger must account for that => the debugger must find the file by its base name.

The debugger tries the full name (with path) first. If that succeeds it will prefer that.
(except blue dots, here it may now (with that patch) always pull in the "name only" => but a breakpoint set would prefer the fullname only, if available)

[Okoba]

Thank you.
The good news is that in the test it is fixed.
But in my original code that I extracted the sample from, it is still not working.
I will try to extract a new sample to show the issue.

[Okoba]

Okay, it seems I found it.
I created a new package, moved the Unit1 to the package and used the package in the project. Made sure to delete any build folder and clean up.
Now, again, it can not debug the Log function, with no blue dots. SimpleLog has blue dots.