Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Jonas:
> Anyway, you're right, the startup code for Linux/x86-64 does not
> pass the libc init/fini routines and hence is broken. And that's
> indeed not something to still change right before the release.
But perhaps you'll want to consider fpc-x86_64-cprt0.patch (attached)
for the trunk. I can confirm that it doesn't break Debian's build.
Perhaps someone else can test it in some other way.
And here's an improved patch for AArch64: fpc-aarch64-cprt0.patch.
AArch64 seems to need a corresponding version of the change that was
needed for i386, so I've included both changes here. (So if you've
already applied the patch from Debian bug #800811 there will be a
conflict.) Apart from the i386 part, this patch could perhaps go into
fixes_3_0_ios as it clearly (I hope) only affects AArch64-Linux so
can't break anything that used to work.
Edmund
--- a/rtl/linux/x86_64/cprt0.as
+++ b/rtl/linux/x86_64/cprt0.as
@@ -63,8 +63,8 @@
pushq %rsp
/* Pass address of our own entry points to .fini and .init. */
- movq _init_dummy@GOTPCREL(%rip), %rcx
- movq _fini_dummy@GOTPCREL(%rip), %r8
+ movq __libc_csu_init@GOTPCREL(%rip), %rcx
+ movq __libc_csu_fini@GOTPCREL(%rip), %r8
movq main_stub@GOTPCREL(%rip), %rdi
@@ -116,18 +116,6 @@
ret
.size _haltproc,.-_haltproc
- .globl _init_dummy
-.type _init_dummy, @function
-_init_dummy:
-ret
- .size _init_dummy,.-_init_dummy
-
- .globl _fini_dummy
-.type _fini_dummy, @function
-_fini_dummy:
-ret
- .size _fini_dummy,.-_fini_dummy
-
/* Define a symbol for the first piece of initialized data. */
.data
.globl __data_start
--- a/fpcsrc/compiler/systems/t_linux.pas
+++ b/fpcsrc/compiler/systems/t_linux.pas
@@ -149,6 +149,14 @@
if not Dontlinkstdlibpath Then
LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/x86_64-linux-gnu',true);
{$endif x86_64}
+{$ifdef i386}
+ if not Dontlinkstdlibpath Then
+LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/i386-linux-gnu',true);
+{$endif i386}
+{$ifdef aarch64}
+ if not Dontlinkstdlibpath Then
+LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/aarch64-linux-gnu',true);
+{$endif aarch64}
end;
{$ifdef m68k}
--- a/fpcsrc/rtl/linux/aarch64/cprt0.as
+++ b/fpcsrc/rtl/linux/aarch64/cprt0.as
@@ -50,16 +50,6 @@
/* This should never happen */
b abort
- .globl _init
- .type _init,#function
-_init:
- ret
-
- .globl _fini
- .type _fini,#function
-_fini:
- ret
-
.globl _haltproc
.type _haltproc,#function
_haltproc:
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Jonas: > Now, for some reason, it seems that right now on Linux we only do this for > x86 and PowerPC (32 and 64 bit). So x86_64 does this the wrong way. So perhaps I should try to fix this on x86_64 (amd64) first because then there will be more people who can test any proposed patch. But it's a bit late for 3.0.0, isn't it? Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Jonas: >> So x86_64 does this the wrong way. > No, with "x86" I meant "i386 and x86_64". Sorry for not being clear. What you wrote was ambiguous, but I interpreted it as just 32-bit because my aarch64 patch, above, makes rtl/linux/aarch64/cprt0.as more similar to rtl/linux/x86_64/cprt0.as. Isn't the x86_64 file doing exactly what Sergei says is wrong? Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Clearly I don't really know what I'm doing with these start-up files... but I found I needed this patch to build the Debian package on arm64, so it's probably something for the AArch64 fixes branch. I tried running the test suite with and without this patch, and it appeared that webtbs/tw28089 went into an infinite loop without the patch and passed with it, but I've never seen that test fail before, and I don't see any connection with the patch, so I suspect there was some kind of random race and this patch does not really make any difference for the test suite. By the way, the failures on powerpc and ppc64 look rather as if they might be start-up-file-related: https://buildd.debian.org/status/package.php?p=fpc=experimental Edmund --- a/rtl/linux/aarch64/cprt0.as +++ b/rtl/linux/aarch64/cprt0.as @@ -41,23 +41,23 @@ _start: init, fini, rtld_fini, stack_end) */ adrpx0,:got:PASCALMAIN ldr x0,[x0,#:got_lo12:PASCALMAIN] - adrpx3,:got:__libc_csu_init - ldr x3,[x3,#:got_lo12:__libc_csu_init] - adrpx4,:got:__libc_csu_fini - ldr x4,[x4,#:got_lo12:__libc_csu_fini] + adrpx3,:got:_init_dummy + ldr x3,[x3,#:got_lo12:_init_dummy] + adrpx4,:got:_fini_dummy + ldr x4,[x4,#:got_lo12:_fini_dummy] bl __libc_start_main /* This should never happen */ b abort - .globl _init - .type _init,#function -_init: + .globl _init_dummy + .type _init_dummy,#function +_init_dummy: ret - .globl _fini - .type _fini,#function -_fini: + .globl _fini_dummy + .type _fini_dummy,#function +_fini_dummy: ret .globl _haltproc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] 3.0.0~rc1 in Debian
Jonas: > As mentioned by Michael Ring, this is a bug in the 2.6.4 Debian ARMHF > compiler that gets triggered by the newer compiler sources. I don't think it > happens with any other FPC 2.6.4 as starting compiler. So I would guess that the solution is to add "OPTLEVEL1=-O-" to the CYCLEOPTS which are used in the following line in debian/rules (https://sources.debian.net/src/fpc/3.0.0~rc1%2Bdfsg-1/debian/rules/#L253): $(MAKE) -C fpcsrc compiler_cycle $(CYCLEOPTS) And this could be done just on armhf, or on all architectures. Thanks, Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] 3.0.0~rc1 in Debian
3.0.0~rc1 has arrived in Debian experimental, but has failed to build on several architectures: https://buildd.debian.org/status/package.php?p=fpc=experimental Debian applies various patches, of course, but I was able to reproduce the i386 failure on Debian unstable with the upstream source, and I've suggested a solution here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800811 The error on armhf is weird. Click on "Build-Attempted" in the appropriate line to see the full log. The error is: flt_pack.inc(119,5) Error: Syntax error while parsing a conditional compiling expression Can anyone say what the problem is there? Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
Just a couple of reactions: Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes. Not really. TCC does a single pass with no intermediate representation. It leaves a gap in the procedure prologue for the code that moves the stack pointer and fills it in when it gets to the end of the function and knows how much space is required for the local variables and temporaries. There have been NO fundamental changes in IT in the last 20 years (probably longer). One could argue that multi-core and concern about security are fairly fundamental changes. Both have lead to people trying to do sophisticated static analysis of code whose use of pointers makes that analysis, in general, rather difficult. Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] aarch64: bug fix in fpPoll
A negative timeout with poll means infinity, but a negative
timespec with ppoll is an error.
Index: rtl/linux/bunxsysc.inc
===
--- rtl/linux/bunxsysc.inc (revision 31023)
+++ rtl/linux/bunxsysc.inc (working copy)
@@ -492,10 +492,15 @@
{$if defined(generic_linux_syscalls)}
var ts : timespec;
begin
- ts.tv_sec := timeout div 1000;
- ts.tv_nsec := (timeout mod 1000) * 100;
- fpPoll:=do_syscall(syscall_nr_ppoll,tsysparam(fds),tsysparam(nfds),
- tsysparam(@ts),0);
+ if timeout0 then
+fpPoll:=do_syscall(syscall_nr_ppoll,tsysparam(fds),tsysparam(nfds),0,0)
+ else
+begin
+ ts.tv_sec := timeout div 1000;
+ ts.tv_nsec := (timeout mod 1000) * 100;
+ fpPoll:=do_syscall(syscall_nr_ppoll,tsysparam(fds),tsysparam(nfds),
+ tsysparam(@ts),0);
+end
end;
{$else}
begin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] no exceptions from arithmetical operations on AArch64
The compiler adds an explicit comparison to ensure that in case of an integer division by zero, a run time error is raised anyway. The same is done on PowerPC, which doesn't trigger an exception for integer division by zero either. As jumps in many cases are slow due to queue issues, this might be a severe performance hit. It's an interesting problem. There may be cases in which you don't need to know about the exception immediately, in which case you could avoid conditional branches by doing a conditional select in the loop, say, and only testing after the loop whether a division by zero has occurred. However, most branch predictors can cope quite well with a branch that is almost never taken. In the case of floating-point operations, the AArch64 hardware does something like that for you: it sets a sticky bit when the exceptional thing has happened. However, testing whether that bit has been set is probably more expensive than checking whether the divisor is zero so you'd want to put off the test until after several operations. How much freedom do you have in the choice of which exceptions you detect and when? Just for a check list, the AArch64 cumulative exception bits are: IXC : Inexact UFC : Underflow OFC : Overflow DZC : Division by Zero IOC : Invalid Operation (I don't have much practical experience of programming with floating-point operations, though I have at times studied what AArch64 instructions do.) Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] git mirror
https://github.com/fpc-svn/fpc.git seems to have stopped updating itself. Does anyone know how to edit a .git/config so that a clone of that git repo can be updated with git-svn, without starting again from r1? http://stackoverflow.com/questions/746151/add-svn-repo-to-existing-git-repo suggests it's possible, but I haven't got it to work yet ... Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] aarch64-linux: PATCH: implement gprt0.as for profiling
Jonas: While that means the test will successfully compile and run, no actual profile information will be generated because there are no calls to mcount in the program (the testsuite does not contain any logic to check whether the generated gprof information by the test program is probably correct). Yes. In fact, if I remember correctly, the test does not even check that gmon.out is created. Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] no exceptions from arithmetical operations on AArch64
Looking through the tests that fail on aarch64-linux I found ten that
depend on an arithmetical operation causing an exception, usually
division by zero:
tbs/tb0262
test/texception4
test/units/math/tmask
test/units/math/tmask2
webtbs/tw3157
webtbs/tw3160a
webtbs/tw3160b
webtbs/tw3160c
webtbs/tw3161
webtbs/tw4100
In AArch64 the instruction for integer division never causes an
exception, and floating-point arithmetic can only cause an exception
if an optional part of the architecture is enabled; most hardware
doesn't even have the option. Clearly the compiler could generate code
to check for exceptions but it would be very inefficient when those
exceptions are not required.
I can't find an explicit statement in the documentation but this
example suggests that exceptions from arithmetical operations are not
required by the language definition:
http://www.freepascal.org/docs-html/ref/refse101.html#x212-22200017.1
So, can those tests be disabled on AArch64, by adding
{ %skipcpu=aarch64 }?
Edmund
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux assembler start-up: rtl/linux/*/*.as
- Would there be four separate Pascal entry points, one for each assembler file? (Each could take arguments: fini, argc, argv, envp.) Presumably various symbols undefined in *prt0.o, defined in the C library, would have to be additional arguments. (Or is there another way of doing it?) Currently these are undefined in gprt0.as on aarch64-linux: U PASCALMAIN U __libc_start_main U __monstartup U _etext U _mcleanup U abort U atexit Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Linux assembler start-up: rtl/linux/*/*.as
Is there a good reason why the Linux start-up is implemented with so much assembler code? There are lots of inexplicable differences between the corresponding files for different architectures, and there are also inexplicable differences between cprt0.as and gprt0.as on some architectures, or between prt0.as and dllprt0.as. When implementing aarch64-linux I spent a lot of time wondering which architecture I should take as a model. As far as I can tell very little in those files has to be implemented in assembler: perhaps just the initial argument marshalling and initialising the frame pointer. The rest could be done in Pascal, presumably, with the code shared between architectures. It would be a lot easier to maintain that way. Some questions to answer if one were going to rewrite that stuff in Pascal: - In which source file would the Pascal code go? - Would there be four separate Pascal entry points, one for each assembler file? (Each could take arguments: fini, argc, argv, envp.) - How to do the equivalent of C longjmp in Pascal, used in x86_64/gprt0.as, for example? Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] aarch64-linux: PATCH: implement gprt0.as for profiling
rtl/linux/aarch64/gprt0.as is based on aarch64/cprt0.as and
x86_64/gprt0.as.
webtbs/tw0876 now passes.
Edmund
diff --git a/compiler/options.pas b/compiler/options.pas
index 390675b..9654ee6 100644
--- a/compiler/options.pas
+++ b/compiler/options.pas
@@ -118,7 +118,7 @@ var
const
{ gprof (requires implementation of g_profilecode in the code generator) }
- supported_targets_pg = [system_i386_linux,system_x86_64_linux,system_mipseb_linux,system_mipsel_linux,system_arm_linux]
+ supported_targets_pg = [system_i386_linux,system_x86_64_linux,system_mipseb_linux,system_mipsel_linux,system_arm_linux,system_aarch64_linux]
+ [system_i386_win32]
+ [system_powerpc_darwin,system_x86_64_darwin]
+ [system_i386_GO32V2]
diff --git a/rtl/linux/aarch64/gprt0.as b/rtl/linux/aarch64/gprt0.as
index e3a1b59..d7d6337 100644
--- a/rtl/linux/aarch64/gprt0.as
+++ b/rtl/linux/aarch64/gprt0.as
@@ -7,4 +7,112 @@
.text
.align 2
- b xx_aarch64_gprt0_unimplemented
+
+ .globl _start
+ .type _start,#function
+_start:
+ /* Initialise FP to zero */
+ mov x29,#0
+
+ /* This is rtld_fini */
+ mov x5,x0
+
+ /* Get argc, argv, envp */
+ ldr x1,[sp]
+ add x2,sp,#8
+ add x11,x1,#1
+ add x11,x2,x11,lsl #3
+
+ /* Save argc, argv, envp, and initial stack pointer */
+ adrp x10,:got:operatingsystem_parameter_argc
+ ldr x10,[x10,#:got_lo12:operatingsystem_parameter_argc]
+ str x1,[x10]
+ adrp x10,:got:operatingsystem_parameter_argv
+ ldr x10,[x10,#:got_lo12:operatingsystem_parameter_argv]
+ str x2,[x10]
+ adrp x10,:got:operatingsystem_parameter_envp
+ ldr x10,[x10,#:got_lo12:operatingsystem_parameter_envp]
+ str x11,[x10]
+ adrp x10,:got:__stkptr
+ ldr x10,[x10,#:got_lo12:__stkptr]
+ mov x6,sp
+ str x6,[x10]
+
+ /* __libc_start_main(main, argc, argv,
+ init, fini, rtld_fini, stack_end) */
+ adrp x0,:got:main_stub
+ ldr x0,[x0,#:got_lo12:main_stub]
+ adrp x3,:got:_init_dummy
+ ldr x3,[x3,#:got_lo12:_init_dummy]
+ adrp x4,:got:_fini_dummy
+ ldr x4,[x4,#:got_lo12:_fini_dummy]
+ bl __libc_start_main
+
+ /* This should never happen */
+ b abort
+
+ .globl _init_dummy
+ .type _init_dummy,#function
+_init_dummy:
+ ret
+
+ .globl _fini_dummy
+ .type _fini_dummy,#function
+_fini_dummy:
+ ret
+
+ .globl main_stub
+ .type main_stub,#function
+main_stub:
+ stp x29,x30,[sp,#-16]!
+
+ /* Save initial stackpointer */
+ mov x0,sp
+ adrp x1,:got:__stkptr
+ ldr x1,[x1,#:got_lo12:__stkptr]
+ str x0,[x1]
+
+ /* Initialize gmon */
+ adrp x0,:got:_start
+ ldr x0,[x0,#:got_lo12:_start]
+ adrp x1,:got:_etext
+ ldr x1,[x1,#:got_lo12:_etext]
+ bl __monstartup
+ adrp x0,:got:_mcleanup
+ ldr x0,[x0,#:got_lo12:_mcleanup]
+ bl atexit
+
+ /* Start the program */
+ bl PASCALMAIN
+ b abort
+
+ .globl _haltproc
+ .type _haltproc,#function
+_haltproc:
+ /* Return to libc */
+ adrp x1,:got:__stkptr
+ ldr x1,[x1,#:got_lo12:__stkptr]
+ ldr x1,[x1]
+ mov sp,x1
+ ldp x29,x30,[sp],#16
+ ret
+
+ /* Define a symbol for the first piece of initialized data. */
+ .data
+ .align 3
+ .globl __data_start
+__data_start:
+ .long 0
+ .weak data_start
+ data_start = __data_start
+
+ .bss
+ .align 3
+
+ .comm __stkptr,8
+
+ .comm operatingsystem_parameter_envp,8
+ .comm operatingsystem_parameter_argc,8
+ .comm operatingsystem_parameter_argv,8
+
+ .section .note.GNU-stack,,%progbits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] aarch64-linux: PATCH: add aarch64-linux to rtl/
This patch includes most of the hard work in porting FPC to aarch64-linux: getting the assembler start-up code roughly right, getting the sizes and layouts of various structs correct, coping with system calls that no longer exist (see dup2/dup3, for example), ... Linux arm64 takes its system call numbers from include/uapi/asm-generic/unistd.h, which according to a quick grep of the kernel source is currently used for these architectures: arc, arm64, c6x, hexagon, metag, nios2, openrisc, score, tile, unicore32. I would guess that arm64 is the first of these to appear in FPC so I've put the generic syscall numbers in rtl/linux/sysnr-gen.inc and I've used generic_linux_syscalls as the condition for alternatives that would presumably be applicable to any of those architectures. With this patch you should be able to get as far as building compiler/ppca64, either cross-building on a supported system or building natively on Linux arm64. Edmund fpc-aarch64-linux-rtl.patch.gz Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] aarch64-linux: PATCH: add aarch64-linux to rtl/
This patch includes most of the hard work in porting FPC to
aarch64-linux: getting the assembler start-up code roughly right,
getting the sizes and layouts of various structs correct, coping with
system calls that no longer exist (see dup2/dup3, for example), ...
Linux arm64 takes its system call numbers from
include/uapi/asm-generic/unistd.h, which according to a quick grep of
the kernel source is currently used for these architectures: arc,
arm64, c6x, hexagon, metag, nios2, openrisc, score, tile, unicore32. I
would guess that arm64 is the first of these to appear in FPC so I've
put the generic syscall numbers in rtl/linux/sysnr-gen.inc and I've
used generic_linux_syscalls as the condition for alternatives that
would presumably be applicable to any of those architectures.
With this patch you should be able to get as far as building
compiler/ppca64, either cross-building on a supported system or
building natively on Linux arm64.
diff --git a/rtl/linux/aarch64/bsyscall.inc b/rtl/linux/aarch64/bsyscall.inc
new file mode 100644
index 000..c690ebe
--- /dev/null
+++ b/rtl/linux/aarch64/bsyscall.inc
@@ -0,0 +1 @@
+{ nothing }
diff --git a/rtl/linux/aarch64/cprt0.as b/rtl/linux/aarch64/cprt0.as
new file mode 100644
index 000..fe41556
--- /dev/null
+++ b/rtl/linux/aarch64/cprt0.as
@@ -0,0 +1,91 @@
+/*
+ Start-up code for Free Pascal Compiler when linking with C library.
+
+ Written by Edmund Grimley Evans in 2015 and released into the public domain.
+*/
+
+ .text
+ .align 2
+
+ .globl _start
+ .type _start,#function
+_start:
+ /* Initialise FP to zero */
+ mov x29,#0
+
+ /* This is rtld_fini */
+ mov x5,x0
+
+ /* Get argc, argv, envp */
+ ldr x1,[sp]
+ add x2,sp,#8
+ add x11,x1,#1
+ add x11,x2,x11,lsl #3
+
+ /* Save argc, argv, envp, and initial stack pointer */
+ adrpx10,:got:operatingsystem_parameter_argc
+ ldr x10,[x10,#:got_lo12:operatingsystem_parameter_argc]
+ str x1,[x10]
+ adrpx10,:got:operatingsystem_parameter_argv
+ ldr x10,[x10,#:got_lo12:operatingsystem_parameter_argv]
+ str x2,[x10]
+ adrpx10,:got:operatingsystem_parameter_envp
+ ldr x10,[x10,#:got_lo12:operatingsystem_parameter_envp]
+ str x11,[x10]
+ adrpx10,:got:__stkptr
+ ldr x10,[x10,#:got_lo12:__stkptr]
+ mov x6,sp
+ str x6,[x10]
+
+ /* __libc_start_main(main, argc, argv,
+init, fini, rtld_fini, stack_end) */
+ adrpx0,:got:PASCALMAIN
+ ldr x0,[x0,#:got_lo12:PASCALMAIN]
+ adrpx3,:got:__libc_csu_init
+ ldr x3,[x3,#:got_lo12:__libc_csu_init]
+ adrpx4,:got:__libc_csu_fini
+ ldr x4,[x4,#:got_lo12:__libc_csu_fini]
+ bl __libc_start_main
+
+ /* This should never happen */
+ b abort
+
+ .globl _init
+ .type _init,#function
+_init:
+ ret
+
+ .globl _fini
+ .type _fini,#function
+_fini:
+ ret
+
+ .globl _haltproc
+ .type _haltproc,#function
+_haltproc:
+ adrpx0,:got:operatingsystem_result
+ ldr x0,[x0,#:got_lo12:operatingsystem_result]
+ ldr w0,[x0]
+ mov w8,#94 // syscall_nr_exit_group
+ svc #0
+ b _haltproc
+
+ /* Define a symbol for the first piece of initialized data. */
+ .data
+ .align 3
+ .globl __data_start
+__data_start:
+ .long 0
+ .weak data_start
+ data_start = __data_start
+
+ .bss
+ .align 3
+
+ .comm __stkptr,8
+
+ .comm operatingsystem_parameter_envp,8
+ .comm operatingsystem_parameter_argc,8
+ .comm operatingsystem_parameter_argv,8
+
+ .section .note.GNU-stack,,%progbits
diff --git a/rtl/linux/aarch64/dllprt0.as b/rtl/linux/aarch64/dllprt0.as
new file mode 100644
index 000..e91b758
--- /dev/null
+++ b/rtl/linux/aarch64/dllprt0.as
@@ -0,0 +1,72 @@
+/*
+ Start-up code for Free Pascal Compiler in a shared library,
+ not linking with C library.
+
+ Written by Edmund Grimley Evans in 2015 and released into the public domain.
+*/
+
+ .text
+ .align 2
+
+ .globl _startlib
+ .type _startlib,#function
+_startlib:
+ .globl FPC_SHARED_LIB_START
+ .type FPC_SHARED_LIB_START,#function
+FPC_SHARED_LIB_START:
+ stp x29,x30,[sp,#-16]!
+
+ /* Save argc, argv and envp */
+ adrpx9,:got:operatingsystem_parameter_argc
+ ldr x9,[x9,#:got_lo12:operatingsystem_parameter_argc]
+ str x0,[x9]
+ adrpx9,:got:operatingsystem_parameter_argv
+ ldr x9,[x9,#:got_lo12:operatingsystem_parameter_argv]
+ str x1,[x9]
+ adrpx9,:got:operatingsystem_parameter_envp
+ ldr x9,[x9,#:got_lo12:operatingsystem_parameter_envp]
+ str x2,[x9]
+
+ /* Save
[fpc-devel] aarch64-linux: PATCH: add aarch64-linux to packages/ tests/ utils/
This patch adds stuff for aarch64-linux to packages/fcl-res, packages/rtl-extra, utils/fpcres/, and tests/webtbs/tw11563.pp. With this patch some fairly respectable test results can be obtained: Compilation failures = 7 Compilation that did not fail while they should = 4 Failed runs = 27 Thank you again to Jonas Maebe for all his help with this! Edmund fpc-aarch64-linux-etc.patch.gz Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] aarch64-linux: PATCH: add aarch64-linux to compiler/
Jonas:
I have a small question about that change:
+{$ifdef AArch64}
+{$define LINKERSCRIPT_INCLUDED}
+ if isdll or (sysrootpath='') then begin
Why do you always do this when creating a library?
I was trying to identify the cases in which -T is not used, but I
may have the logic wrong. Is DllCmd, without --T, not used to create
a library?
It would be clearer to have a boolean variable called linker_opt_t
controlling both things, but I'm not sure where to put it.
Edmund
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] aarch64-linux: PATCH: add aarch64-linux to compiler/
There are not a lot of changes here: mostly just filling in a few gaps
that were helpfully left for me to fill in. The most interesting
change is in t_linux.pas, where I had to do something a bit different
with linker scripts and -T. There's a comment in the code there.
Running on a supported system,
make all OS_TARGET=linux CPU_TARGET=aarch64 \
BINUTILSPREFIX=aarch64-linux-gnu- FPC=fpc
gets you as far as the cross-compiler, compiler/ppcrossa64.
diff --git a/compiler/aarch64/agcpugas.pas b/compiler/aarch64/agcpugas.pas
index 4aa2a88..c3895e5 100644
--- a/compiler/aarch64/agcpugas.pas
+++ b/compiler/aarch64/agcpugas.pas
@@ -39,6 +39,10 @@ unit agcpugas;
procedure WriteInstruction(hp : tai);override;
end;
+ TAArch64Assembler=class(TGNUassembler)
+constructor create(smart: boolean); override;
+ end;
+
TAArch64AppleAssembler=class(TAppleGNUassembler)
constructor create(smart: boolean); override;
function MakeCmdLine: TCmdStr; override;
@@ -69,6 +73,16 @@ unit agcpugas;
{}
+{ AArch64 Assembler writer }
+{}
+
+constructor TAArch64Assembler.create(smart: boolean);
+ begin
+inherited create(smart);
+InstrWriter := TAArch64InstrWriter.create(self);
+ end;
+
+{}
{ Apple AArch64 Assembler writer}
{}
@@ -99,6 +113,8 @@ unit agcpugas;
const
darwin_addrpage2str: array[addr_page..addr_gotpageoffset] of
string[11] =
('@PAGE','@PAGEOFF','@GOTPAGE','@GOTPAGEOFF');
+linux_addrpage2str: array[addr_page..addr_gotpageoffset] of string[10]
=
+ ('',':lo12:',':got:',':got_lo12:');
begin
if ref.base=NR_NO then
begin
@@ -117,8 +133,7 @@ unit agcpugas;
if target_asm.id=as_darwin then
result:=ref.symbol.name+darwin_addrpage2str[ref.refaddr]
else
-{ todo }
-internalerror(2014121502);
+result:=linux_addrpage2str[ref.refaddr]+ref.symbol.name
end
else
internalerror(2015022301);
@@ -160,8 +175,7 @@ unit agcpugas;
if target_asm.id=as_darwin then
result:=result+',
'+ref.symbol.name+darwin_addrpage2str[ref.refaddr]
else
-{ todo }
-internalerror(2014122510);
+result:=result+',
'+linux_addrpage2str[ref.refaddr]+ref.symbol.name
end
else
{ todo: not yet generated/don't know syntax }
@@ -269,6 +283,19 @@ unit agcpugas;
const
+ as_aarch64_gas_info : tasminfo =
+ (
+id : as_gas;
+idtxt : 'AS';
+asmbin : 'as';
+asmcmd : '-o $OBJ $EXTRAOPT $ASM';
+supported_targets : [system_aarch64_linux];
+flags : [af_needar,af_smartlink_sections];
+labelprefix : '.L';
+comment : '// ';
+dollarsign: '$';
+ );
+
as_aarch64_gas_darwin_info : tasminfo =
(
id : as_darwin;
@@ -284,5 +311,6 @@ unit agcpugas;
begin
+ RegisterAssembler(as_aarch64_gas_info,TAArch64Assembler);
RegisterAssembler(as_aarch64_gas_darwin_info,TAArch64AppleAssembler);
end.
diff --git a/compiler/aarch64/cgcpu.pas b/compiler/aarch64/cgcpu.pas
index dcec48d..471c318 100644
--- a/compiler/aarch64/cgcpu.pas
+++ b/compiler/aarch64/cgcpu.pas
@@ -171,7 +171,7 @@ implementation
the address of the entry itself from that page (can be relaxed by
the linker in case the variable itself can be stored directly in
the GOT) }
-if target_info.system in systems_darwin then
+if target_info.system in (systems_darwin + systems_linux) then
begin
if (preferred_newbasereg=NR_NO) or
(ref.base=preferred_newbasereg) or
@@ -1631,9 +1631,7 @@ implementation
procedure tcgaarch64.g_maybe_got_init(list : TAsmList);
begin
-{ nothing to do on Darwin; check on ELF targets }
-if not(target_info.system in systems_darwin) then
- internalerror(2014112601);
+{ nothing to do on Darwin or Linux }
end;
diff --git a/compiler/aarch64/cputarg.pas b/compiler/aarch64/cputarg.pas
index a05c853..584a295 100644
--- a/compiler/aarch64/cputarg.pas
+++ b/compiler/aarch64/cputarg.pas
@@ -36,7 +36,7 @@ implementation
[fpc-devel] aarch64-linux: PATCH: add aarch64-linux to fpmkunit and fpcmake
I'll be sending a sequence of patches that add aarch64-linux support
to FPC. This is the first, or the second if you include the RelocType
change in packages/fcl-res, which isn't AArch64-specific.
A big thank-you to Jonas Maebe for guiding me through this work and
answering all my questions.
This tiny patch is for the build system and implies a big patch to all
the Makefiles when fpcmake is run
(utils/fpcm/bin/*/fpcmake -Tall `find -name Makefile.fpc`).
diff --git a/packages/fpmkunit/src/fpmkunit.pp
b/packages/fpmkunit/src/fpmkunit.pp
index cd0dc07..4de0d54 100644
--- a/packages/fpmkunit/src/fpmkunit.pp
+++ b/packages/fpmkunit/src/fpmkunit.pp
@@ -186,7 +186,7 @@ Const
OSCPUSupported : array[TOS,TCpu] of boolean = (
{ os none i386m68k ppcsparc x86_64 armppc64 avr
armeb mips mipsel jvmi8086 aarch64 }
{ none }( false, false, false, false, false, false, false, false,
false, false, false, false, false, false, false),
-{ linux } ( false, true, true, true, true, true, true, true,
false, true , true , true , false, false, false),
+{ linux } ( false, true, true, true, true, true, true, true,
false, true , true , true , false, false, true ),
{ go32v2 } ( false, true, false, false, false, false, false, false,
false, false, false, false, false, false, false),
{ win32 } ( false, true, false, false, false, false, false, false,
false, false, false, false, false, false, false),
{ os2 } ( false, true, false, false, false, false, false, false,
false, false, false, false, false, false, false),
@@ -2629,6 +2629,7 @@ begin
x86_64: result := GetGccDirArch('cpux86_64','-m64');
powerpc: result := GetGccDirArch('cpupowerpc','-m32');
powerpc64:result := GetGccDirArch('cpupowerpc64','-m64');
+ aarch64: result := GetGccDirArch('cpuaarch64','');
end {case}
else if OS = darwin then
case CPU of
diff --git a/utils/fpcm/fpcmmain.pp b/utils/fpcm/fpcmmain.pp
index 61a3efc..fead2e3 100644
--- a/utils/fpcm/fpcmmain.pp
+++ b/utils/fpcm/fpcmmain.pp
@@ -114,7 +114,7 @@ interface
{ This table is kept OS,Cpu because it is easier to maintain (PFV) }
OSCpuPossible : array[TOS,TCpu] of boolean = (
{ os i386m68k ppcsparc x86_64 armppc64 avr
armeb armel mips mipsel mips64 misp64el jvmi8086 aarch64}
-{ linux } ( true, true, true, true, true, true, true, false,
true, false, true, true, false, false, false, false, false),
+{ linux } ( true, true, true, true, true, true, true, false,
true, false, true, true, false, false, false, false, true ),
{ go32v2 } ( true, false, false, false, false, false, false, false,
false, false, false, false, false, false, false, false, false),
{ win32 } ( true, false, false, false, false, false, false, false,
false, false, false, false, false, false, false, false, false),
{ os2 } ( true, false, false, false, false, false, false, false,
false, false, false, false, false, false, false, false, false),
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] aarch64-linux: PATCH: small change in packages/fcl-res
packages/fcl-res/src/: Make RelocType and fRelocType longword. They were previously byte, which is not big enough for Elf64. --- packages/fcl-res/src/elfsubwriter.inc |2 +- packages/fcl-res/src/elfwriter.pp |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/packages/fcl-res/src/elfsubwriter.inc b/packages/fcl-res/src/elfsubwriter.inc index 3da0abf..144370b 100644 --- a/packages/fcl-res/src/elfsubwriter.inc +++ b/packages/fcl-res/src/elfsubwriter.inc @@ -27,7 +27,7 @@ type _TElfRelocTable_= class private fList : TFPList; -fRelocType : byte; +fRelocType : longword; fEntrySize : integer; fSectionType : integer; fSectionName : string; diff --git a/packages/fcl-res/src/elfwriter.pp b/packages/fcl-res/src/elfwriter.pp index e6de496..dc157d0 100644 --- a/packages/fcl-res/src/elfwriter.pp +++ b/packages/fcl-res/src/elfwriter.pp @@ -155,7 +155,7 @@ type type TElfRelocInfo = record -RelocType : byte; +RelocType : longword; SectionType : integer; end; (* -- 1.7.10.4 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] fpcmake does not recurse into utils/ and packages/
Is this a bug? utils/fpcm/bin/i386-linux/fpcmake -Tall -r recursed into most subdirectories, but the build later failed in utils/fpcm (I think) with the complaint that aarch64-linux was not supported. I observed that the Makefiles in that part of the tree had not been updated. I had to do something like this: for x in `find packages utils -type d` ; do ( cd $x /home/ege/fpc/utils/fpcm/bin/i386-linux/fpcmake -Tall ) done After that, make all OS_TARGET=linux CPU_TARGET=aarch64 BINUTILSPREFIX=aarch64-linux-gnu- finished without an error. Is this expected behaviour, or a bug? If it's not expected, could someone else please try running fpcmake -Tall -r in fpc/ and then checking with ls -lrt utils/*/Makefile whether those files have been updated? Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AArch64 port committed to svn trunk
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AArch64 port committed to svn trunk
Jonas Maebe jonas.ma...@elis.ugent.be:
You indeed have to include the equivalents of
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=29877 (in
i_linux.pas) and
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=29897 (in
t_linux.pas).
Thanks.
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.
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AArch64 port committed to svn trunk
Jonas Maebe jonas.ma...@elis.ugent.be:
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!
Ah yes, you also still have to include that unit in the AArch64
compiler, see compiler/aarch64/cputarg.pas
Thanks. That's excellent. I'm now getting errors from t_linux.pas so I
can start experimenting with putting something sensible there.
Edmund
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
