Lazarus for Windows on aarch64 (ARM64) - Native Compiler

[CuriousKit]

I've got one of the bugs fixed for you chaps!

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/691

I'm taking a look at the next one, which I predict is going to be a bit more complex.

[DonAlfredo]

Good work. Thanks !!

[CuriousKit]

No problem - glad to help.  Onto the next puzzle.

[DonAlfredo]

I have some small fixes for this target too. Will share them with you when my time permits.

[msintle]

I've got one of the bugs fixed for you chaps!

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/691

I'm taking a look at the next one, which I predict is going to be a bit more complex.

Thank you so much for this, and also confirming receipt of the bug bounty (and your patience with the prolonged payout process)!

Looking forward to your nailing the other fix - so we can fully erect Lazarus on aarch64 for Win32!!!

[Igor Kokarev]

Hi,

Thanks for the recent improvements with fpc for win11/aarch64!

Please can you remind me a link to any page where described current status of Win/aarch64 for FPC/Lazarus?

I recently installed Windows 11 ARM64 on my Mac mini M1 via Parallels Desktop. Can I try to compile a console app with a target win/aarch64?

[Wallaby]

I don't believe there is any page describing the current state of things.

In short, simple console programs that don't use exceptions compiled for win64-aarch64 work fine. That using the trunk compiler.

You can use fpcupdeluxe to cross-compile from macOS or Windows, but be sure to install the correct cross-compiler in fpcupdeluxe.

[Igor Kokarev]

Wallaby,

Thanks for your reply!

I use exceptions in my apps, so I guess that it can be a problem with current trunk compiler aarch64.

[abouchez]

I just looked at the current state of the FPC trunk, and some preliminary win64-aarch64 exception support do actually exist in rtl\win64 since 4 years.
https://gitlab.com/freepascal.org/fpc/source/-/commit/4e06d66d7fb98e634e4e86a1d43f3856da429fec
https://gitlab.com/freepascal.org/fpc/source/-/commit/4236bee6f1832b11845869ffe99cb8ea0a96a230

My guess is that this is pretty much not debugged, but the RTL was made ready to support win64-aarch64.

Since my company need this, I will try to look into this in the next weeks.

[abouchez]

I have some small fixes for this target too. Will share them with you when my time permits.

Can you share it with me, please, Alfred?

[DonAlfredo]

I hope you will succeed in getting FPC working on Win64Arm !!

Seems all patches are lost unfortunately. The USB-stick is gone.
However, I remember some of it. All related to the data-structures in rtl\win64\seh64.inc
Comparing the definitions in winnt.h and seh64.inc, some (small) deviations can be found.

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

1.   KNONVOLATILE_CONTEXT_POINTERS=record
2.     IntegerContext: array[0..12] of PQWord; <------------------ arm64 : 11 and not 12
3.     FloatingContext: array[0..7] of PM128A;
4.   end;
5.  

I did some work on the exception handling, but again, the work is lost unfortunately. The small things above are all that I could recover (from memory).

[abouchez]

Thanks @DonAlfredo for the feedback.

I will try to follow your indications.
I have found a general - old but still accurate - guide to SEH at https://www-user.tu-chemnitz.de/~heha/hsn/chm/Win32SEH.chm

If anyone else as some additional input, you are welcome to react here!

[abouchez]

Here is what I fixed so far:

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

1. c:\fpcupdeluxe\fpcsrc\rtl\win64>git diff seh64.inc
2. diff --git a/rtl/win64/seh64.inc b/rtl/win64/seh64.inc
3. index 774cc2bbc9..28281152ab 100644
4. --- a/rtl/win64/seh64.inc
5. +++ b/rtl/win64/seh64.inc
6. @@ -158,8 +158,8 @@   TContext = record
7.    { This is a simplified definition, only array part of unions }
8.    PKNONVOLATILE_CONTEXT_POINTERS=^KNONVOLATILE_CONTEXT_POINTERS;
9.    KNONVOLATILE_CONTEXT_POINTERS=record
10. -    IntegerContext: array[0..12] of PQWord;
11. -    FloatingContext: array[0..7] of PM128A;
12. +    IntegerContext: array[0..11] of PQWord; // X19..X28 + Fp + Lr
13. +    FloatingContext: array[0..7] of PM128A; // D8..D15
14.    end;
15.  {$endif NOT (X86_64 or AARCH64)}
16.  
17. @@ -181,12 +181,12 @@   TExceptionPointers = record
18.    RUNTIME_FUNCTION=record
19.      BeginAddress: DWORD;
20.      EndAddress: DWORD;
21. -    UnwindData: DWORD;
22. +    UnwindData: DWORD; // or UnwindInfoAddress
23.    end;
24.  {$elseif defined(CPUAARCH64)}
25.    RUNTIME_FUNCTION=record
26.      BeginAddress: DWORD;
27. -    UnwindData: DWORD;
28. +    UnwindData: DWORD; // or Flag(2) Len(11) RegF(3) RegI(4) H(1) CR(2) FSize(9)
29.    end;
30.  {$endif}
31.  
32. @@ -224,6 +224,7 @@   TDispatcherContext = record
33.  {$elseif defined(CPUAARCH64)}
34.      ControlPCIsUnwound: Byte;
35.      NonVolatileRegisters: PByte;
36. +    Reserved: DWord;
37.  {$endif}
38.    end;
39.  

I don't know if it is enough, but at least now it matches winnt.h definitions.

[Wallaby]

It looks like apart from the wrong size of KNONVOLATILE_CONTEXT_POINTERS, the real issue is that the compiler generates incorrect unwinding information and when an exception occurs Windows cannot unwind the stack and call exception handlers.

I have updated my bug report accordingly.

[msintle]

It looks like apart from the wrong size of KNONVOLATILE_CONTEXT_POINTERS, the real issue is that the compiler generates incorrect unwinding information and when an exception occurs Windows cannot unwind the stack and call exception handlers.

I have updated my bug report accordingly.

@CuriousKit, does this help?