Print Page - Broken debugging of generic codes

Programming => General => Topic started by: Okoba on January 28, 2025, 03:52:56 pm

Title: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 03:52:56 pm

I was using an old (2023) version of Lazarus and generics and they were working almost fine, they are buggy all the time.
Today I wanted to test late 2024 Lazarus and no debugging feature is working and I am puzzled if this is a setup issue or not. I have a couple of Lazarus on Windows 10 x64 from end of 2024 with default settings and installed by fpcupdelux. All of them can not wait on the breakpoint!
Can anyone tell me if this is a issue on my system or is this something known?

Code: Pascal [Select][+]

program project1;
 
{$mode objfpc}
 
uses
  Unit1;
 
  procedure Test;
  begin
   specialize Log<integer>;
  end;
 
begin
  Test;
  ReadLn;
end.

Code: Pascal [Select][+]

unit Unit1;
 
{$mode objfpc}
 
interface
 
generic function Log<T>: integer; overload;
 
implementation
 
generic function Log<T>: integer;
begin
  WriteLn('xxx'); //Breakpoint on this line shows as invalid and green
end;
 
end.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 04:28:58 pm

Checked again with Trunk of right now (Lazarus 4.99 (rev dc6183cb78) FPC 3.3.1 x86_64-win64-win32/win64)
Same problem with breakpoints and I get:
"Execution stopped with exit-code -1073741510 ($C000013A)"

Title: Re: Broken debugging of generic codes
Post by: Thaddy on January 28, 2025, 05:16:30 pm

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.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 05:18:10 pm

How can I debug the specialized version of the Log procedure?

Title: Re: Broken debugging of generic codes
Post by: Thaddy on January 28, 2025, 05:19:47 pm

by defining the specialization as a type.
then the compiler knows beforehand.
this is quite basic and easy.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 05:28:18 pm

How?
And why I could do it on previous FPC versions?

Title: Re: Broken debugging of generic codes
Post by: Thaddy on January 28, 2025, 05:38:34 pm

You can still do it like in the previous versions.
I suspect that you expect too much.
Regarding this subject nothing has changed.
You can't debug a generic without a specialization at some point:
that is impossible, because there is no code.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 05:44:09 pm

No in previous versions I can debug the procedure.
Not now.

Are you saying "It is impossible to debug a generic method"?
If not, please tell me how can I do it, step by step as I can not understand your point.

Title: Re: Broken debugging of generic codes
Post by: Thaddy on January 28, 2025, 05:50:17 pm

Ask PascalDragon,
He will point out the same thing:
If a generic is not specialized in any way there is no code.
That has always - and will be - the case, because generics are templates.

What you suggest is imposible.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 05:53:50 pm

Okay thank you.

This topic is still open for anyone verifying that it is impossible or a way to debug.
I am very sadly surprised that I can not debug such code!

Title: Re: Broken debugging of generic codes
Post by: cdbc on January 28, 2025, 06:08:54 pm

Hi
Hmmmm, this:

Code: Pascal [Select][+]

program project1;
 
{$mode objfpc}
 
uses
  Unit1;
 
  procedure Test;
  begin
   specialize Log<integer>; //<-- does nothing
  end;
 
begin
  Test;
  ReadLn;
end.

doesn't do anything...
Maybe:

Code: Pascal [Select][+]

  procedure Test(anInt: integer);
  begin
   specialize Log<integer>(anInt); //<-- calls log
  end;
 
begin
  Test(42);
  ReadLn;
end.

the above can make it do something, so that it doesn't get optimized away?!?
I dunno, just a thought...
Regards Benny

Title: Re: Broken debugging of generic codes
Post by: bytebites on January 28, 2025, 06:27:26 pm

Silly rant again. Someone is unable to read code.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 28, 2025, 06:32:18 pm

I don't know exactly what your previous version was...

And, most likely your issue is not with the version of Lazarus, but the version of FPC you are using. That means, you may have used an older Lazarus, but maybe with a 3.2.3 fixes version of FPC?

Anyway, as far as I remember....

Generics compiled with older versions of FPC did not work with breakpoints. (or "not always"). I do not recall what exactly "older version" that was => but it may have been 3.2.2. And it may be that the fix is in 3.2.3.

The issue (if memory serves) was, that
- if you had a generic in one unit (e.g. generics.collection) with code in lines 100 to 150
- you had a "specialize ThatGeneric<...>" in your unit "UnitFoo"
- Then the compiler would tell the debugger that the lines where in UnitFoo from 100 to 150. Meaning you had to set the breakpoint there (of course there would be another procedure there, and that would be in the way).

However the above was from tests with generic classes.
I have not tested generic functions like that.

Please also note that

Code: Pascal [Select][+]

type TFoo = object
procedure Bar;
 

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

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 28, 2025, 06:37:58 pm

Anyway I just tested your example with 4.99 (and fpc 3.2.2 as well as 3.2.3)

And I can set breakpoints in any of the functions.

That is on Windows 64 bit

EDIT: 3.3.1 also works for me / though my 3.3.1 is a bit older

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 06:43:50 pm

@bytebites I do not get your comment. What is you version of FPC?
@Martin_fr thank you so much. Lets forget about the older version, and to try to be more specific I tried the today version of trunk of FPC and Lazarus, all default settings, and Windows 64bit and the code I sent and it shows as invalid and green!
Tested version: Lazarus 4.99 (rev dc6183cb78) FPC 3.3.1 x86_64-win64-win32/win64
My working older version is from 2024-09-02 and FPC 3.3.1 and Lazarus 3.99.

I installed all these with Trunk button on fpcupdelux that installs the latest of FPC and Lazarus.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 28, 2025, 06:45:38 pm

Are you using FpDebug or GDB?

Possible that something changed if FPC that I don't have yet. Not sure if I'll have time to update tonight.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 06:49:16 pm

Everything is out of the box. In IDE options it shows FpDebug internal Dwarf-debugger, and Project options build mode is Default and type of debug info is Dwarf 3.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 28, 2025, 06:49:42 pm

In fpc (at least if installed normally) there is a tool called objdump

You can use that
objdump.exe --dwarf=decodedline yourprog.exe

And it will show you what fpc tells the debugger.
1) In which units there is code at which line
2) At which address those lines are.

Before you set the breakpoint, are there blue dots at those lines?

If there are not, but the objdump show that those lines are included, then look at the addresses. They may be wrong (e.g. 0x1000 which would be unusual low)

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 06:57:37 pm

I added another procedure and called it, it has the blue dots but not the generic one.
Here is the output, it seems it has the lines 18,19 and 20 of unit1.pas!

Code: Pascal [Select][+]

Decoded dump of debug contents of section .debug_line:
 
CU: project1.lpr:
File name                            Line number    Starting address
 
./unit1.pas:[++]
unit1.pas                                     18         0x1000015c0
unit1.pas                                     19         0x1000015cd
unit1.pas                                     20         0x1000015f8
project1.lpr                                   9         0x100001610
project1.lpr                                  10         0x100001619
project1.lpr                                  11         0x10000161e
project1.lpr                                  12         0x100001623
project1.lpr                                  14         0x100001630
project1.lpr                                  15         0x10000163e
project1.lpr                                  16         0x100001643
project1.lpr                                  17         0x100001658
 
CU: unit1.pas:
File name                            Line number    Starting address
unit1.pas                                     13         0x10000e140
unit1.pas                                     14         0x10000e14d
unit1.pas                                     15         0x10000e178
 

Title: Re: Broken debugging of generic codes
Post by: bytebites on January 28, 2025, 07:00:57 pm

Versions are Lazarus 4.99 and Fpc trunk Linux.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 28, 2025, 07:35:09 pm

The output of objdump looks ok.

Now there may be 2 issues (one of which I can reproduce).

1) The non-generic function does not have blue dots (but should).
- I do get that issue too. (even with fpc 3.2.3)
- I can step in F7
- I can not set a breakpoint in the non generic function

2) The invalid breakpoint in the generic function
- I do not get that.

For the 2nd issue:
* Do you compile with -O- (no optimizations) or -O1? Does changing this makes a difference?
* When you are in "procedure Test" at the line that calls the generic log => Can you open the asm window and use the step-in-asm button in the asm window to step into that procedure?
* Does the address match the output of objdump?
* Does the asm show any source lines/names?
* What does the asm look like?

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 28, 2025, 07:54:18 pm

It might actually be the same issue.

Looking into it.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 07:58:27 pm

1) I can go into `Log` if I set breakpoint in `Test` and use F7. But still it will shown as invalid breakpoint. This is my problem in my original project (that I extracted this sample code) and I know from experience that after a couple of lines in the generic function using F8 or F7, debugger will loose itself and shows random lines or leave the generic function.
2) Everything is default, so it uses -O1. Changing to no optimization does not change anything.

While preparing screenshots for you, I found out that if I rename the project folder or move it someplace else, breakpoint works and blue dots are shown! It seems something is cached and linked to the path, so if I change the path, it will work. Cleaning up the project and removing `lib` folder and exe is not helping, only changing the path!
In the screenshot, you can see two IDE, both running the same project, and using F7 it came into the generic procedure. Left is the project from original path and right is that project, copied and folder is renamed from `test` to `test2`.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 28, 2025, 08:38:45 pm

It may depend on some order during compile or link.

Basically unit1 does get handled both, as
c:\full\path\unit1.pas
unit.pas

Which is allowed, but only one gets found.

Which may depend. (maybe if you recompile, and only project got rebuild).

---
If you look close, in the image where the generic has the blue dots, they are missing from the non generic.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 08:44:53 pm

I tried clean up build and deleted any built file, no change. And It only get more complicated when the generic code is in a unit in a package.
Is it somehow my computer issue? How no one reported such issue?!

Any idea how can we debug this more and find and hopefully solve this issue?

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 28, 2025, 09:03:37 pm

I have found at least one issue that I believe causes this.

So for now, you can consider it as reported.

I will let you know when I fixed the issue (or the issue that I found) => if then it still exists then we need to dig deeper.

If it is what I think, then it got broken on 16th November 2024. (by me, sorry). I am not sure, the issue may have existed before, but if it has, it was hidden deeper, and maybe less likely to ever cause a problem. The change on 16th Nov however either started or affected it.

Since it only affects code with generics, and not always all generics, it simply had not yet been spotted.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 28, 2025, 09:13:03 pm

Forget the 16th. My bad, its older.

The issue is in 4.0rc too => and the changed of 16th Nov is not in 4.0.

But I still know what causes it. Only have to find a way to fix it.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 09:15:22 pm

Great news to hear a confirmation. Thaddy made me doubt my whole understanding of generics :)
Thank you. I will wait for any result from you and will continue checking until resolved.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 28, 2025, 09:23:04 pm

Quote from: Okoba on January 28, 2025, 09:15:22 pm

Great news to hear a confirmation. Thaddy made me doubt my whole understanding of generics :)
Thank you. I will wait for any result from you and will continue checking until resolved.

IMHO Thaddy's answer are 50%/50%/50%

- 50% ok
- 50% not ok
- 50% ok, but misleading

But he will ensure you that all 150% are of the first kind ;) ;) Or in his words: >:D >:D >:D

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 28, 2025, 09:27:29 pm

If I don't know him already, I would be angry :D

Title: Re: Broken debugging of generic codes
Post by: PascalDragon on January 28, 2025, 11:32:05 pm

Quote from: Thaddy on January 28, 2025, 05:16:30 pm

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 😅 ).

Quote from: Martin_fr on January 28, 2025, 06:32:18 pm

Please also note that
Code: Pascal [Select][+][-]
type TFoo = object
procedure Bar;

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? 🤔

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 12:42:03 am

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.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 01:09:19 am

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.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 06:30:02 am

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?

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 09:54:53 am

Quote from: Okoba on January 29, 2025, 06:30:02 am

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

Quote

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.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 10:17:58 am

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.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 10:45:51 am

Quote from: Okoba on January 29, 2025, 10:17:58 am

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).

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 10:50:05 am

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.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 11:29:51 am

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.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 11:31:40 am

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

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 11:51:51 am

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.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 11:58:24 am

Quote from: PascalDragon on January 28, 2025, 11:32:05 pm

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.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 01:10:10 pm

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)

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 03:22:45 pm

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.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 03:34:52 pm

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.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 04:15:18 pm

Quote from: Okoba on January 29, 2025, 03:34:52 pm

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.

And that is with just/only the first patch (current official main branch)?

Or that is with the additional patch (from my private mirror / not yet in main)?

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 05:04:09 pm

That was the main branch. I missed that the second one is from your repo and not the main.
I am now compiling with your patch and will report back soon.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 05:16:35 pm

With the patch, it is solved in the package case too, but still has issue in the original project. I am trying to create a new test project to show the issue.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 05:29:18 pm

I made a new test, that as you can see there is no blue dots and if you try to step the code with F8, it will jump to some random unknown place.
It seems a mix of multiple units and package.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 05:33:07 pm

I found an issue opened by me 4 years ago, and assigned to you. It seems similar to this one.
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/38200
From the related post, it seems fixed at that time: https://forum.lazarus.freepascal.org/index.php/topic,52048
But something changed along the way, or it is related to GDB/Fpdebug change.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 05:58:00 pm

Quote from: Okoba on January 29, 2025, 05:29:18 pm

I made a new test, that as you can see there is no blue dots and if you try to step the code with F8, it will jump to some random unknown place.
It seems a mix of multiple units and package.

That is an issue in the compiler. Check with objdump. For unit1 there are only 3 lines. The lines 23 to 26 are incorrectly listed in unit2 (even unit2 does not have such lines)

It is likely https://gitlab.com/freepascal.org/fpc/source/-/issues/38209
(Which was created with a link (mantis) to your issue / I updated that for gitlab now).

That issue got assigned to me, as I analysed it. But it was forward reported as child issue to the fpc.
I initially kept the original issue open as a placeholder. But I closed it now. Just follow the fpc issue please.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 05:59:22 pm

Thank you very much for the check. I will follow it. Should I mention any particular developer to check it?

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 29, 2025, 06:03:55 pm

1) I don't think it was fixed. The related forum post is likely wrong (you probably had some lucky change in the code that made it to work for that case only).

2) I unfortunately don't know who in the FPC team would best be addressed for this.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 29, 2025, 06:05:37 pm

Thank you again.

Title: Re: Broken debugging of generic codes
Post by: PascalDragon on January 30, 2025, 09:35:05 pm

Quote from: Martin_fr on January 29, 2025, 11:58:24 am

Quote from: PascalDragon on January 28, 2025, 11:32:05 pm
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.

At least with the 3.0 I still use my main issue isn't the blue dots and placing breakpoints, but accessing fields or even parameters which works with GDB.

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 30, 2025, 10:50:39 pm

Quote from: PascalDragon on January 30, 2025, 09:35:05 pm

At least with the 3.0 I still use my main issue isn't the blue dots and placing breakpoints, but accessing fields or even parameters which works with GDB.

Examples, please?

I know that old style "object" does not show parems (except with fpc trunk), but that is both gdb and fpdebug (afaik).

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 30, 2025, 10:52:27 pm

You may experience this in "finally" or "except" blocks (which IIRC works partly / maybe better in 4.0)

That is because they are a subroutine, but do not have debug info. FpDebug tries to find the real routine. But then gdb would not....

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on January 31, 2025, 01:28:18 am

I made some small changes to my 2nd part of the fix. I committed them to main now.

Please test them again, if you can. Thanks.

Title: Re: Broken debugging of generic codes
Post by: Okoba on January 31, 2025, 10:18:06 am

I checked with today main and nothing changed in the test with package that I attached for you in earlier posts.

Title: Re: Broken debugging of generic codes
Post by: PascalDragon on February 02, 2025, 10:08:34 pm

Quote from: Martin_fr on January 30, 2025, 10:50:39 pm

Quote from: PascalDragon on January 30, 2025, 09:35:05 pm
At least with the 3.0 I still use my main issue isn't the blue dots and placing breakpoints, but accessing fields or even parameters which works with GDB.

Examples, please?

I know that old style "object" does not show parems (except with fpc trunk), but that is both gdb and fpdebug (afaik).

Seems like I was mistaken there. My main issue is htypechk.tcallcandidates and that was “recently” changed from class to object... 😕

Title: Re: Broken debugging of generic codes
Post by: Martin_fr on February 02, 2025, 11:14:58 pm

Quote from: PascalDragon on February 02, 2025, 10:08:34 pm

Seems like I was mistaken there. My main issue is htypechk.tcallcandidates and that was “recently” changed from class to object... 😕

Then there are 2 options:

1) use FPC 3.3.1.
That should work. Fields, and locals in methods of that object.

Though, if you use inheritance, And have a variable of the base class, it might not be able to easily show the inherited.

This should work:
^TChildObjType(@TheBaseObjVar)^

2) Watch from outside.
While you are in a method, you can't see the object. There is no self, and local vars don't work.
No solution for locals. :( (not that I know)
But the object often is a variable in one of the callers, switch to that callers and inspect that var. It is plenty work, but works.
I guess / not tested: You can take the address, and use the typecast via pointer and then you can step without having to switch stack frame all the time.

Also not tested, but if you know which register holds self: ^TFoo(%rax)^
You should even be able to do math ^^TFoo((%RBP)^+1)^ // the one adds sizeof(pointer) => its pointer math. otherwise ^TFoo(^Byte(%rbp)+42)^ // requires to know where on the RBP it is stored...

EDIT: actually rbp is a number no need for the inner cast: ^TFoo(rbp+10)^

None of that is perfect. But at least maybe something.