Lazarus for Windows on aarch64 (ARM64) - Native Compiler

[Wallaby]

Forgot to mention if you are going to build this with FpcupDeluxe, you can simply add the patches and rebuild.

However, I remember having some issues with older LLVM included in FpcupDeluxe's cross-tools, I recommend using CLANG + LLVM 21 as there are quite a few fixes related to Win64 ARM64:

Issue D114347: ADRP Signed/Unsigned 21-bit Interpretation
Issue D113865: Temporary Symbols Out-of-Range for ADRP
Issue D34964: ARM64 Import Thunk Implementation

[Fred vS]

@Wallaby: You are extremely precious.

[Wallaby]

I might have figured out why RtlUnwind wasn't working on ARM64. Will post an update soon, we may be able to simplify a lot...

[ALLIGATOR]

I'm being told that I need to look at how it's done in C++, and that it's all about constructing the frame pointer correctly
(but I don't understand this issue myself)

[ALLIGATOR]

View - by compiling similar code in C++

[Wallaby]

Guys, ignore the above patches, that was a workaround rather than a solution.

I've got RtlUnwindEx working and will provide a better set of patches shortly!

There was an issue with FPC SEH PDATA generation.

[Wallaby]

🎉 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!

[440bx]

I don't have an ARM64 based device but, I strongly believe you deserve virtual high-fives for your efforts, therefore here is mine: high-five!

[ALLIGATOR]

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?

[Wallaby]

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.

[msintle]

We have both Snapdragons for native Windows 11, and Parallels on arm64 Macs for virtualized Windows 11.

Funny note: Virtualizing Windows 11 on arm64 macOS is far easier than virtualizing Windows 11 on Snapdragon itself, thanks to the horrid product that is called Hyper-V.

Of course, you could go native only on Snapdragon; as Boot Camp has been removed on arm64 Macs for some reason.

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?

Very excited to see all the progress that is being made.

[msintle]

First of the company itself did not contribute itself, but “only” offered a bounty in the hope that someone would attempt to fix the issues.

Second in the discussion back then - which I've now looked up and funnily enough was also about aarch64-win64, so it's not even that long ago - we came to the conclusion that people should sponsor work for the sake of functionality and not for the sake of brand awareness.

If companies want to be mentioned somewhere they should donate to the Foundation and request to be put on the Hall of Fame.

In this case the company offered a respectable bounty, IMO, while not direct, it is still a contribution.  The person who did the work may not have done the work as promptly or at all if a respectable bounty had not been available. 

The company explicitly sponsored work and _after_ the work was done asked if it could get some credit for sponsoring it.  I believe that is fair.  They invested into getting some work done, therefore they contributed.  Also, I don't see anything wrong in a company offering a bounty for the further development of an already approved feature that is in their interest instead of throwing money into a foundation that may invest it into something that offers little to no benefit to them.  When someone (person or entity) puts money into something, I believe it is reasonable for them to expect a little something back for their financial investment and goodwill.

What you call "The Hall of Fame" seems to be the "Hall of the Unknown".  There are _very_, _very_ few places where I see credit given to an author and when given it seems to be more to acknowledge copyrights than anything else (e.g, API definitions.)  As a result of your mentioning "The Hall of Fame" (or lack thereof) I looked it up and found it.  What their contribution is/was isn't even mentioned, I guess they contributed money (made a donation.)  How many of them invested $10,000 in enhancing FPC ?

I am fully aware that my opinion doesn't carry any weight but, if those who contribute aren't given a modicum of credit, that doesn't encourage further contributions which is detrimental. 

Anyway, personally I believe the current "credit for contributions" could be "improved".

Thank you for this.

It is clear to me that Lazarus will continue to have tons of untapped potential, lagging behind in areas like GTK, Qt, on Linux as we all know - and even on Macs, falling behind in SDK support, even silly things like rounded corners on macOS Tahoe don't work months after release - thanks to policies which are primarily defensive in posture, but serving only to stunt the growth of this awesome effort.

[msintle]

We had a discussion about something like this in the past already and came to the conclusion that we don't do that.

That's quite understandable since what could start as "innocent" attributions could devolve in shameless marketing.

OTH, if attributions were allowed under strict guidelines to avoid abuses, that might encourage companies to financially invest in the development of FPC (and possibly Lazarus under similar conditions.)  We all know that having sponsors is better than not having them.

Sounds reasonable that if a company contributed in some way to enhancing something that they'd be given credit for it while ensuring "credit" isn't abused into becoming marketing.

First of the company itself did not contribute itself, but “only” offered a bounty in the hope that someone would attempt to fix the issues.

Second in the discussion back then - which I've now looked up and funnily enough was also about aarch64-win64, so it's not even that long ago - we came to the conclusion that people should sponsor work for the sake of functionality and not for the sake of brand awareness.

If companies want to be mentioned somewhere they should donate to the Foundation and request to be put on the Hall of Fame.

At risk of inflaming a possibly senior compiler developer here:

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.

[Wallaby]

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.

It is clear to me that Lazarus will continue to have tons of untapped potential, lagging behind in areas like GTK, Qt, on Linux as we all know - and even on Macs, falling behind in SDK support, even silly things like rounded corners on macOS Tahoe don't work months after release - thanks to policies which are primarily defensive in posture, but serving only to stunt the growth of this awesome effort.

On that point, I agree with you. Free Pascal has a number of issues in its development policies, priorities and long-term vision (>5 years between releases; these days one might reasonably assume the product is abandoned and move on). In addition, the developers tend to focus on their own areas of interest.

That said, it is free and open-source, so we cannot really blame them for this — it is their choice — even though it is clearly not good for the project’s long-term health or popularity.

Take the ARM64 exceptions issue as an example: the bug report has been sitting unresolved for years. I have customers who are increasingly asking for ARM64 builds of my products, so I took matters into my own hands and wasted spent several days getting it done. Hopefully the developers will accept the patches, but if not, that only makes things worse for the project. In the meantime, I — and anyone else who needs this functionality — can simply use the patches and move on.

[440bx]

In the meantime, I — and anyone else who needs this functionality — can simply use the patches and move on.

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.