[replying on the list to a private message with consent from the original poster]

Compiler: mostly adding support for the GNU syntax to the assembler writer (compiler/aarch64/agcpugas.pas). Apart from that, possibly adding support for ELF-specific symbol addressing (e.g. GOT-related things) and possibly adding support for non-PIC code if that is supported (iOS only supports/uses PIC on AArch64) (compiler/aarch64/cgcpu.pas, tcgaarch64.make_simple_ref -- at least the first "{ todo }" part, or verify what can be reused from the existing code for Darwin). Possibly also add support for the GNU memory reference assembler syntax to compiler/aarch64/racpugas.pas (search for "LO12").

RTL: add Linux startup and syscall code for AArch64 (rtl/linux/aarch64, base on rtl/linux/{powerpc64,i386,x86_64}/si_*.inc if possible), and Linux signal/sigcontext
support(rtl/linux/aarch64/{sighnd.inc,sighndh.inc}). Verify/fix various types used for kernel interfacing (statfs etc -- see rtl/linux/{ostypes.inc,osdefs.inc,ossysc.inc,termios.inc})

fpcmake and fpmkunit: add the Linux/AArch64 target (see http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=29899 and http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=29902 )

The above command regenerated the top-level makefile using the fpcmake that was in your path. This is probably the fpcmake from the latest official release. Since that release had no AArch64 support, this removed any AArch64 support that the Makefile may have had.

You only have to use that command if you want to regenerate a Makefile either after modifying the corresponding Makefile.fpc, or after modifying the fpcmake program to add support for a new target (such as Linux/AArch64). In this latter case you have to regenerate all Makefiles rather than on only the top-level one though, e.g. using fpcmake -Tall `find . -name Makefile.fpc`

As mentioned above, you probably overwrote the Makefile with one that does not have support for Darwin/AArch64 anymore. Note that building for Darwin generally doesn't work on non-Darwin platforms, as the GNU binutils don't support it. You may be able to use
https://github.com/tpoechtrager/osxcross , but I've never tried it myself.

Jonas

Thanks for those explanations.

I modified packages/fpmkunit/src/fpmkunit.pp and
utils/fpcm/fpcmmain.pp by analogy with revisions 29899 and 29902, then:

make all
utils/fpcm/bin/i386-linux/fpcmake -Tall -r
make all OS_TARGET=linux CPU_TARGET=aarch64

After a while it objects to a missing aarch64/prt0.as, but it has already made compiler/ppcrossa64. Naturally, this is still a Darwin compiler:

$ compiler/ppcrossa64 /dev/null
Free Pascal Compiler version 3.1.1 [2015/05/09] for aarch64 Copyright (c) 1993-2015 by Florian Klaempfl and others Target OS: Darwin for AArch64

Now I think this might be because of the code in compiler/systems.pas with the comment "change to Linux" ... so I do that, and I add system_aarch64_linux to the list in compiler/systems.inc. (Note, by the way, that "{ 85 }" occurs twice in that file. Is that a bug?)

Now I get:

$ compiler/ppcrossa64 /dev/null
Fatal: Internal error 2004121202

Now this is perhaps not surprising as I know I have to modify compiler/systems/i_linux.pas and compiler/systems/t_linux.pas, presumably by analogy with [it]_bsd.pas, but I find I can put whatever I like in those files bracketed with {$ifdef aarch64} or {$ifdef cpuaarch64} and it has no effect because those symbols are never defined there, it seems.

So something fundamental is still missing.

Any suggestions?

(I haven't modified compiler/aarch64/agcpugas.pas yet, but I don't think I've got that far yet, and those symbols are not mentioned in that file.)

Thanks,

Edmund

Note that while the compiler binary always only supports one target architecture (or sometimes even sub-architecture, like with ARMEL/ARMEL-HF), it always supports all targets OSes for that given (sub-)architecture. The default target OS is normally explicitly set to be the same as host OS (if the target architecture is supported on the host OS). As you noticed, for AArch64 since there is only support for Darwin right now, it's always Darwin though.

Now I think this might be because of the code in compiler/systems.pas with the comment "change to Linux" ... so I do that, and I add system_aarch64_linux to the list in compiler/systems.inc. (Note, by the way, that "{ 85 }" occurs twice in that file. Is that a bug?)

It's indeed a copy/paste error, although won't have any effect ("{ }" is equivalent to "/* */" in C).

Now I get: $ compiler/ppcrossa64 /dev/null Fatal: Internal error 2004121202

That means the compiler is trying to create a compiler define with an empty name. It may indeed be related to the target OS not being properly set or registered, as the compiler will define a system with the target OS name. Including correct versions of the revisions mentioned below will probably solve that.

Now this is perhaps not surprising as I know I have to modify compiler/systems/i_linux.pas and compiler/systems/t_linux.pas, presumably by analogy with [it]_bsd.pas,

You indeed have to include the equivalents of
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=29877 (in i_linux.pas) and
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=29897 (in t_linux.pas).

In case of the i_linux.pas changes, make sure to change the name, shortname, flags, unit_env, extradefines, sharedlibext and all other settings mentioning either bsd, macho, darwin to something that's the same as for other Linux targets in the i_linux.pas file. Also use abi_default rather than abi_aarch64_darwin.

For t_linux.pas, you will need more changes, because we currently (wrongly/superfluously) include the entire target linker script in the compiler for that OS (even when using the external linker), slightly modified to add the .fpc section. You can get the linker script via "aarch64-linux-gnu-ld --verbose" (without any other parameters).

but I find I can put whatever I like in those files bracketed with {$ifdef aarch64} or {$ifdef cpuaarch64} and it has no effect because those symbols are never defined there, it seems.

Code bracketed with {$ifdef aarch64} is included if you are compiling a compiler that targets AArch64, regardless of the host architecture.

Code bracketed with {$ifdef cpuaarch64} is included if you are compiling a compiler that is hosted on AArch64, regardless of its target architecture (or in general: if you are compiling code for AArch64).

(I haven't modified compiler/aarch64/agcpugas.pas yet, but I don't think I've got that far yet, and those symbols are not mentioned in that file.)

Indeed.

Jonas

Jonas Maebe :

Thanks.

I've put this in t_linux.pas:

{$ifdef aarch64}
xx xx xx
{$endif aarch64}

But I'm getting compiler/ppcrossa64 without getting an error!

Edmund

Ah yes, you also still have to include that unit in the AArch64 compiler, see compiler/aarch64/cputarg.pas

Jonas

Jonas Maebe :

Thanks. That's excellent. I'm now getting errors from t_linux.pas so I can start experimenting with putting something sensible there.

Edmund