Broken debugging of generic codes

[Okoba]

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][+][-]

1. program project1;
2.  
3. {$mode objfpc}
4.  
5. uses
6.   Unit1;
7.  
8.   procedure Test;
9.   begin
10.    specialize Log<integer>;
11.   end;
12.  
13. begin
14.   Test;
15.   ReadLn;
16. end.

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

1. unit Unit1;
2.  
3. {$mode objfpc}
4.  
5. interface
6.  
7. generic function Log<T>: integer; overload;
8.  
9. implementation
10.  
11. generic function Log<T>: integer;
12. begin
13.   WriteLn('xxx'); //Breakpoint on this line shows as invalid and green
14. end;
15.  
16. end.

[Okoba]

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

[Thaddy]

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.

[Okoba]

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

[Thaddy]

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

[Okoba]

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

[Thaddy]

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.

[Okoba]

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.

[Thaddy]

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.

[Okoba]

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!

[cdbc]

Hi
Hmmmm, this:

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

1. program project1;
2.  
3. {$mode objfpc}
4.  
5. uses
6.   Unit1;
7.  
8.   procedure Test;
9.   begin
10.    specialize Log<integer>; //<-- does nothing
11.   end;
12.  
13. begin
14.   Test;
15.   ReadLn;
16. end.

doesn't do anything...
Maybe:

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

1.   procedure Test(anInt: integer);
2.   begin
3.    specialize Log<integer>(anInt); //<-- calls log
4.   end;
5.  
6. begin
7.   Test(42);
8.   ReadLn;
9. end.

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

[bytebites]

Silly rant again. Someone is unable to read code.

[Martin_fr]

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][+][-]

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)

[Martin_fr]

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

[Okoba]

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