FPC 3.2.4-rc1 available

[Martin_fr]

https://gitlab.com/freepascal.org/fpc/source/-/issues/41431

[pleumann]

Thanks for your effort, guys! I'm really looking forward to the new version!

Is there any chance that someone has a look at fixing stack traces (-gl) for MacOS in this release or is it too late / too difficult?

[PascalDragon]

Is there any chance that someone has a look at fixing stack traces (-gl) for MacOS in this release or is it too late / too difficult?

Is this even fixed in main? If not, though luck.

[pleumann]

Is there any chance that someone has a look at fixing stack traces (-gl) for MacOS in this release or is it too late / too difficult?

Is this even fixed in main? If not, though luck.

I admit I didn't check. And I've never tried to build FPC from source (as opposed to Lazarus, which I routinely build myself). Maybe I should. I was kind of hoping that it's just a small glitch in the specific binary format that slipped into 3.2.2 back then and broke stack traces for MacOS. Is there an open ticket for it? I did search the issue tracker, but couldn't find anything (maybe due to using the wrong search terms). Anyway, this is really my biggest wish for 3.2.4 or another (hopefully not too distant) future version of FPC. Debugging without getting source code information in case of a crash is really a major PITA.

[Martin_fr]

Is there any chance that someone has a look at fixing stack traces (-gl) for MacOS in this release or is it too late / too difficult?

Is this even fixed in main? If not, though luck.

I think, I've read in another post that it is implemented in 3.3.1. But I have not tested myself.

Debugging without getting source code information in case of a crash is really a major PITA.

In general (and afaik it works on Mac, but I don't have one to test), if
- you get the trace with addresses only
- and your app has debug info

then you can in Lazarus go to menu: View > Leaks and traces.
Paste the addresses there, press resolve and select the exe (not sure if that is the bundle, or the exe inside the bundle...).
And then you should get the addresses.

Outside of Lazarus, there may be a way to translate addresses using lldb (or gdb), but that is more work...

[pleumann]

Is there any chance that someone has a look at fixing stack traces (-gl) for MacOS in this release or is it too late / too difficult?

Is this even fixed in main? If not, though luck.

I think, I've read in another post that it is implemented in 3.3.1. But I have not tested myself.

Debugging without getting source code information in case of a crash is really a major PITA.

In general (and afaik it works on Mac, but I don't have one to test), if
- you get the trace with addresses only
- and your app has debug info

then you can in Lazarus go to menu: View > Leaks and traces.
Paste the addresses there, press resolve and select the exe (not sure if that is the bundle, or the exe inside the bundle...).
And then you should get the addresses.

Outside of Lazarus, there may be a way to translate addresses using lldb (or gdb), but that is more work...

My main/problem use case is a command-line app (Lazarus apps I can simply run through the debugger and catch exceptions there). When I compile with "-gl" for Windows or Linux, I get file/line info in case of a crash (like a range error or so). For MacOS (both Intel and Arm) I only get the list of addresses. I assume that basically the same mechanism at work for all three platform (at least the docs didn't seem to contain an obvious hint that I need to do something special for MacOS).

Pasting the hex address into a dialog and letting the compiler resolve it reminds me of Turbo Pascal 3.0 or even earlier. But thanks for the hint. I might try that. If it works it's still better than plastering the code with WriteLn statements.

[JdeHaan]

Next to -gl also include -Xg (Use external debug symbols file). That might help.

[freq]

Hi,
I recently updated to macOS 26 and still get the "malformed method list atom 'ltmp5' or 'ltmp4'" linker error with FPC 3.2.4-rc1 as well as with main branch FPC 3.3.1. Is that issue adressed at all? Of coarse the -WM10.9 flag helps. Compiling for aarch64.
Best

[PascalDragon]

Was that even reported? I can't find something related to this in the issue tracker, so if none of the developers didn't find it by accident by themselves, then of course it's not fixed.

[Thaddy]

Although I can understand that our M4's did have some difficulties - solved-  to install on, the question you answered is not repeatable.
Looks bogus to me and without further information I can not test that.
(and that was the reason I bought it in the first place)

[PeterBB]

Likely affecting the RC / Found in 3.2.3 420f7af213

There is an issue in the code generator.

Under some circumstances inlined code will use the same physical memory in its stackframe for one of its own locals (params),
as the containing code does use for one of its locals.

Ouch!   Can inlining be completely disabled somehow?
I notice that Lazarus source makes extensive use of the 'inline;' directive.

Also I'm curious as to what compilation option '-uni' does (in issue 41431).

Cheers,
Peter

[Thaddy]

Why would you want to disable it?
But yes if you want slower  code you can use {$inline off} in your units locally or use the global commandline option -Si- (or -O- a.k.a. everything off)
I guess you do not fully understand what inline does and where to use it?
Strange question.
Also note inline is a hint: there is no guarantee that the compiler will inline everything that is marked inline.

[PeterBB]

Why would you want to disable it?

Because I would like to do some testing with 3.2.4-rc1,
but that seems pointless given
https://gitlab.com/freepascal.org/fpc/source/-/issues/41431

unless there is a way to guarantee that inlining (which can generate bad code) is always disabled,
even when the 'inline;' directive is used.

Any ideas regarding the -uni option (in the linked bug report, "Steps to Reproduce")?

Cheers,
Peter

[Martin_fr]

Because I would like to do some testing with 3.2.4-rc1,
but that seems pointless given
https://gitlab.com/freepascal.org/fpc/source/-/issues/41431

Just to add, I tested https://gitlab.com/freepascal.org/fpc/source/-/issues/41431#note_2815280197 with the current 3.2.2 => same bug.

[PeterBB]

Because I would like to do some testing with 3.2.4-rc1,
but that seems pointless given
https://gitlab.com/freepascal.org/fpc/source/-/issues/41431

Just to add, I tested https://gitlab.com/freepascal.org/fpc/source/-/issues/41431#note_2815280197 with the current 3.2.2 => same bug.

Ah, thanks for clarifying. I had assumed incorrectly that this was a regression.