Lazarus for Windows on aarch64 (ARM64) - Native Compiler

[Wallaby]

The problem with going that route is that the programmer ends up using a customized, i.e, non-supported, version of the compiler.  In the long run, that's a mountain of headaches that become impractical to deal with.

No one is saying it is perfect 🙂 But the choice is simple: either you do not have the functionality you need, or you patch it to work the way you want. I have another example here.

There was a change to generics.hashes.pas that broke it on Darwin x86_64, and that change was applied to both main and fixes_3_2. I reported the issue and attached a patch. It was accepted into main, but not into fixes_3_2, so that branch remains broken, and my request to merge the fix into the fixes branch was ignored.

As a result, I simply use a fixes_3_2 build for daily work with my patch applied on top. In practice, this causes zero problems and fully solves the issue for me (while others, unfortunately, are still stuck with the buggy version). It is not that you are locked to a specific compiler version; rather, you are using a customised build that addresses what is important to you.

[tofutim]

Hi Wallaby,

I saw your [MR !1268](https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1268) (Reply #171) — great to see the full SEH fix and 44+ test cases.

I’d been working on the same try...finally+exit issue from your minimal test (Reply #67 / [GitLab #40203](https://gitlab.com/freepascal.org/fpc/source/-/issues/40203)) and ended up with a minimal approach: for aarch64-win64 the compiler emits a call to `_FPC_local_unwind` (RtlUnwindEx) instead of a plain jump when leaving a try block via exit/break/continue, and the RTL implements that helper. No frame-pointer or PDATA changes — just that one path. The minimal test (begin → try → exit → finally → end) prints "finally" on Windows ARM64.

I’ve put that in a separate MR with CI so it’s easy to compare or cherry-pick: [!1276](https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1276), with a passing run on `windows-11-arm` here: [GitHub Actions run 21584281219](https://github.com/gig8/fpc/actions/runs/21584281219). Scope is deliberately small (no ppca64, no self-compile).

If maintainers prefer your full fix in !1268, that’s fine by me — just wanted to share the minimal variant and CI in case it’s useful. Happy to help test !1268 or compare notes.

**MR !1268 (Wallaby):** [ARM64 Windows SEH – full fix](https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1268) 
**MR !1276 (this one):** [aarch64-win64: fix try...finally+exit (minimal + CI)](https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1276) 
**CI proof for !1276:** [run 21584281219](https://github.com/gig8/fpc/actions/runs/21584281219)

🎉 ARM64 Windows SEH Finally Works! (MR !1268 needs testers)

  Hey everyone!

  After many hours of debugging, head-scratching, and probably too much coffee ☕, I'm happy to announce that I've
  submitted a merge request to fix exception handling on Windows ARM64!

  The Bug: #40203
  The Fix: MR !1268

  What was broken?

  If you tried using Exit, Break, or Continue inside a try/finally block on Windows ARM64... well, let's just say the
  finally block had other plans. 🙈 It simply didn't run, and your program would crash or behave mysteriously.

  What's fixed?

  Several things actually!
 

• The frame pointer dance 💃 - Windows ARM64 is quite picky about the frame pointer value you pass to
    RtlUnwindEx - it must be FP+16, not just FP. Who knew 16 bytes could cause so much trouble?
• ADRP relocation calculation 🔧 - The internal linker was computing page-relative relocations incorrectly.
    The addend needs to be added to the target address before computing the page difference, not after. This one
    was sneaky!
• SP-relative temp access in finally handlers - ARM64 uses SP-relative addressing for temps (unlike x64 which
     uses RBP-relative). The $fin$ handler has its own stack, so we now convert the addresses properly.
• Threadvar alignment - Ensuring 8-byte alignment on 64-bit platforms, because ARM64 atomic operations really
     don't like misaligned data. 😤

  I've tested this extensively with 44+ test cases covering:
 

• Basic try/except/finally
• Exit/Break/Continue in try/finally
• Nested exception blocks (5+ levels deep!)
• For-in loops with exception handling
• Complex control flow scenarios
• And more...

  🧪 Call for testers!

  If you have a Windows ARM64 device (Surface Pro X, Snapdragon laptops, etc.), please give this a spin! The more
  testing we do, the more confident we can be that this fix is solid.

  Apply the patches from the MR to FPC trunk, rebuild, and let me know if anything breaks or if you find edge cases I
  missed.

  Any feedback, questions, or virtual high-fives are welcome! 🙌

  Cheers!

[Wallaby]

Yeah, there were a few more issues like the alignment fix (otherwise silent crash) and RtlUnwind did not work correctly for local unwind because of incorrect PDATA records (exceptions were okay, but exit/break/continue were not).

I haven't tested your patch, but try running my 44-test set. They all pass on x64 and on arm64 with my patches, would be interesting to see how they work with yours.

[msintle]

Anyways, are there installation instructions for the latest version of Free Pascal/Lazarus, so we can get down and dirty testing your work thus far against our existing code base?

Download FpcupDeluxe here and drop it into any folder.

Click the Setup+ button, then find Source patching – Add FPC patch and add all seven patches listed there (in the Open File dialog, choose *Patch* as the file type). Select trunk for both FPC and Lazarus. Then simply click Install/Update FPC and Lazarus. Make sure the bottom log mentions the patches succesfully applied.

Once that is done, go to the Cross tab, choose aarch64 and Windows, and click Install compiler. Agree to download the cross-tools and wait. When everything is finished, you will have a full Lazarus package and three compilers (Win i386, Win x64 and Win aarch64).

Start Lazarus using the BAT file and you should be able to build for Windows on ARM by setting the target processor to aarch64 and the target system to Win64.

These instructions worked for me on aarch64 Windows 11 when I installed the 32-bit version of Lazarus itself (attempting to install the 64-bit version of Lazarus caused a failure in the FPCUPDLX process).

I was able to create and run an empty project1.exe GUI app and verify that the platform shows as pure Arm64 in the Windows 11 Task Manager.

I was also able to create and build an empty DLL.

Now comes the real testing

[PascalDragon]

By the way, does anyone have a ready-made recipe for running Windows ARM in QEMU on x86_64 Windows?
Maybe everything is already preconfigured and ready to run?

I've tried that, but it was painfully slow and unreliable even running on a 6Ghz 13900KS.

Better get a mac-mini and run in Parallels, or a snapdragon-based laptop.

I personally use a Pi 4 and run Windows 10 there through KVM-accelerated QEMU. Works well enough for tests (though maybe I'll upgrade to a Pi 5 in the future).

Why do you find it funny that the previous request was also about aarch64-win64? Because you think in every other area Lazarus is already perfect, a done deal, with no room for growth and/or improvement left?

Or is it funny that the company chose the most strategic area for development that begged for improvement, and continues to press this agenda forward in spite of your opposition - and may have even succeeded now, despite your best efforts to block progress by exercising a degree of control that is, by now clearly seen to be, unwarranted and counterproductive to all users of the product?

I'd say, get used to FPC/Lazarus outgrowing you and your control. This incident has demonstrated that despite your efforts to backpedal, no matter how "well" they may be intentioned; your creation has already grown beyond you.

It's not the point that multiple bounties were offered to help motivate fixing the issues that I find funny (or better “ironic”), but since you directly asked: it's ironic that it was you and your company who asked for attestation back then and were denied and asked now again and - surprise - are denied.

[msintle]

It's not the point that multiple bounties were offered to help motivate fixing the issues that I find funny (or better “ironic”), but since you directly asked: it's ironic that it was you and your company who asked for attestation back then and were denied and asked now again and - surprise - are denied.

Oh that's a lot less venom than I was prepared for - says a lot about the relative maturity of this community.

You are certainly free to deny any approval in code comments per our earlier request.

The company remains free to take full credit for bringing Lazarus (and Free Pascal) to aarch64 on Windows, ahead of even Delphi itself!

Regarding the bounty, we had already anticipated this development and made alternative arrangements for its delivery.

So this looks like a win-win-win for everyone so far

[Tourniquet]

Anyways, are there installation instructions for the latest version of Free Pascal/Lazarus, so we can get down and dirty testing your work thus far against our existing code base?

Download FpcupDeluxe here and drop it into any folder.

Click the Setup+ button, then find Source patching – Add FPC patch and add all seven patches listed there (in the Open File dialog, choose *Patch* as the file type). Select trunk for both FPC and Lazarus. Then simply click Install/Update FPC and Lazarus. Make sure the bottom log mentions the patches succesfully applied.

Once that is done, go to the Cross tab, choose aarch64 and Windows, and click Install compiler. Agree to download the cross-tools and wait. When everything is finished, you will have a full Lazarus package and three compilers (Win i386, Win x64 and Win aarch64).

Start Lazarus using the BAT file and you should be able to build for Windows on ARM by setting the target processor to aarch64 and the target system to Win64.

Wow thank you very much! So far it seems to work. I've noticed that it's important to use the linked FpcupDeluxe version. I did try it with a different one before but it failed.

[msintle]

Wow thank you very much! So far it seems to work. I've noticed that it's important to use the linked FpcupDeluxe version. I did try it with a different one before but it failed.

Can you please confirm the linked version URL?

It does not seem to load at all for me here, I used the latest stock version from the releases page, but it fails on some devices still (notably, native ones).

[PascalDragon]

Oh that's a lot less venom than I was prepared for - says a lot about the relative maturity of this community.

Well, I originally had one with a bit more venom, then I took a breath and let it stew a bit

[msintle]

Well, I originally had one with a bit more venom, then I took a breath and let it stew a bit

I appreciate that!

Fact is, we have all accomplished something huge to celebrate here, big time

[Tourniquet]

Wow thank you very much! So far it seems to work. I've noticed that it's important to use the linked FpcupDeluxe version. I did try it with a different one before but it failed.

Can you please confirm the linked version URL?

It does not seem to load at all for me here, I used the latest stock version from the releases page, but it fails on some devices still (notably, native ones).

github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/v2.4.0h/fpcupdeluxe-i386-win32.exe

This one worked fine for me.

[msintle]

This one worked fine for me.

That's the one I used.

Funnily it fails in the second phase of instructions (cross-compiling) on native Snapdragon hardware (Surface Laptop 7), but runs on Windows 11 hosted inside Parallels running on aarch64 Macs.

[PascalDragon]

Please note that even with the current fixes by Wallaby there are still issues with the implicit finally-blocks if they're executed as part of an exception path and managed parameters types are involved. Just as a warning for anyone who thinks they can rely on it now.

[Tourniquet]

This one worked fine for me.

That's the one I used.

Funnily it fails in the second phase of instructions (cross-compiling) on native Snapdragon hardware (Surface Laptop 7), but runs on Windows 11 hosted inside Parallels running on aarch64 Macs.

Hmm sounds weird. For me it worked fine in the latest Windows 11 25H2 Version on native Snapdragon Hardware (Surface Pro 9 5g)

[msintle]

Please note that even with the current fixes by Wallaby there are still issues with the implicit finally-blocks if they're executed as part of an exception path and managed parameters types are involved. Just as a warning for anyone who thinks they can rely on it now.

Can you give an example so we can see what to avoid, for example?