We never switched fpc (the Free Pascal Compiler) to the armhfp (hard float) ABI. Would anyone who is familiar with the procedure like to help with this?
The bug tracking this is:
https://bugzilla.redhat.com/show_bug.cgi?id=1491788
As far as I can tell, Debian has an fpc package which is relatively close in version to Fedora's, and it does no longer need any upstream patches for armhfp.
Thanks, Florian
On Thu, Sep 14, 2017 at 8:11 PM, Florian Weimer fweimer@redhat.com wrote:
We never switched fpc (the Free Pascal Compiler) to the armhfp (hard float) ABI. Would anyone who is familiar with the procedure like to help with this?
The bug tracking this is:
https://bugzilla.redhat.com/show_bug.cgi?id=1491788
As far as I can tell, Debian has an fpc package which is relatively close in version to Fedora's, and it does no longer need any upstream patches for armhfp.
I thought Hans had done this in the past [1] and it has previously worked did we regress it at some point? It might also be worth while looking at bootstrapping ppc64le and aarch64 [2] at the same time.
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=455287 [2] http://wiki.freepascal.org/FPC_New_Features_Trunk#New_compiler_targets
On 09/14/2017 09:31 PM, Peter Robinson wrote:
On Thu, Sep 14, 2017 at 8:11 PM, Florian Weimer fweimer@redhat.com wrote:
We never switched fpc (the Free Pascal Compiler) to the armhfp (hard float) ABI. Would anyone who is familiar with the procedure like to help with this?
The bug tracking this is:
https://bugzilla.redhat.com/show_bug.cgi?id=1491788
As far as I can tell, Debian has an fpc package which is relatively close in version to Fedora's, and it does no longer need any upstream patches for armhfp.
I thought Hans had done this in the past [1] and it has previously worked did we regress it at some point?
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=455287
We regressed. fpc-2.6.2-4.fc20.armv7hl produces VFP instructions:
[root@calxeda-arm-soc-04 tmp]# cat t.pas var i: real;
begin Read (i); WriteLn (i + 3.0); end. [root@calxeda-arm-soc-04 tmp]# fpc -g -O2 t.pas Free Pascal Compiler version 2.6.2 [2013/08/08] for arm Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Linux for ARMHF Compiling t.pas Assembling program Linking t /usr/bin/ld: warning: link.res contains output sections; did you forget -T? 6 lines compiled, 0.4 sec [root@calxeda-arm-soc-04 tmp]# objdump -d --reloc t | grep -25 vadd.f64 | head -n 30
0001018c <PASCALMAIN>: 1018c: e92d4010 push {r4, lr} 10190: e24dd010 sub sp, sp, #16 10194: e28dc008 add ip, sp, #8 10198: ec8c8b02 vstmia ip, {d8} 1019c: eb000e95 bl 13bf8 <FPC_INITIALIZEUNITS> 101a0: e3a00000 mov r0, #0 101a4: ec400b10 vmov d0, r0, r0 101a8: eb001c63 bl 1733c <fpc_get_input> 101ac: e1a04000 mov r4, r0 101b0: e1a0100d mov r1, sp 101b4: e1a00004 mov r0, r4 101b8: eb001e5d bl 17b34 <fpc_read_text_float> 101bc: eb000e72 bl 13b8c <FPC_IOCHECK> 101c0: ed9d8b00 vldr d8, [sp] 101c4: e1a00004 mov r0, r4 101c8: eb001e4f bl 17b0c <FPC_READ_END> 101cc: eb000e6e bl 13b8c <FPC_IOCHECK> 101d0: eb001c6a bl 17380 <fpc_get_output> 101d4: e1a04000 mov r4, r0 101d8: e59f203c ldr r2, [pc, #60] ; 1021c <PASCALMAIN+0x90> 101dc: e3e01000 mvn r1, #0 101e0: e59f0038 ldr r0, [pc, #56] ; 10220 <PASCALMAIN+0x94> 101e4: ed900b00 vldr d0, [r0] 101e8: ee380b00 vadd.f64 d0, d8, d0 101ec: e1a03004 mov r3, r4 101f0: e3a00001 mov r0, #1 101f4: eb001d68 bl 1779c <fpc_write_text_float> 101f8: eb000e63 bl 13b8c <FPC_IOCHECK>
I can't get dynamic linking to work (and ppcarm itself is statically linked), but the binary embeds the correct program interpreter:
[root@calxeda-arm-soc-04 tmp]# strings -a /usr/bin/ppcarm | grep /lib/ld-linux /lib/ld-linux-armhf.so.3
How do you want to proceed? We have a hacked glibc in F26 and earlier which happens to run FPC softfloat binaries with the old program interpreter. I can restore that to F27 and rawhide if this helps to restore armhfp/EABIHF support, but maybe this is counterproductive because it obscures problems.
Thanks, Florian
On Thu, Sep 14, 2017 at 8:51 PM, Florian Weimer fweimer@redhat.com wrote:
On 09/14/2017 09:31 PM, Peter Robinson wrote:
On Thu, Sep 14, 2017 at 8:11 PM, Florian Weimer fweimer@redhat.com wrote:
We never switched fpc (the Free Pascal Compiler) to the armhfp (hard float) ABI. Would anyone who is familiar with the procedure like to help with this?
The bug tracking this is:
https://bugzilla.redhat.com/show_bug.cgi?id=1491788
As far as I can tell, Debian has an fpc package which is relatively close in version to Fedora's, and it does no longer need any upstream patches for armhfp.
I thought Hans had done this in the past [1] and it has previously worked did we regress it at some point?
[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=455287
We regressed. fpc-2.6.2-4.fc20.armv7hl produces VFP instructions:
[root@calxeda-arm-soc-04 tmp]# cat t.pas var i: real;
begin Read (i); WriteLn (i + 3.0); end. [root@calxeda-arm-soc-04 tmp]# fpc -g -O2 t.pas Free Pascal Compiler version 2.6.2 [2013/08/08] for arm Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Linux for ARMHF Compiling t.pas Assembling program Linking t /usr/bin/ld: warning: link.res contains output sections; did you forget -T? 6 lines compiled, 0.4 sec [root@calxeda-arm-soc-04 tmp]# objdump -d --reloc t | grep -25 vadd.f64 | head -n 30
0001018c <PASCALMAIN>: 1018c: e92d4010 push {r4, lr} 10190: e24dd010 sub sp, sp, #16 10194: e28dc008 add ip, sp, #8 10198: ec8c8b02 vstmia ip, {d8} 1019c: eb000e95 bl 13bf8 <FPC_INITIALIZEUNITS> 101a0: e3a00000 mov r0, #0 101a4: ec400b10 vmov d0, r0, r0 101a8: eb001c63 bl 1733c <fpc_get_input> 101ac: e1a04000 mov r4, r0 101b0: e1a0100d mov r1, sp 101b4: e1a00004 mov r0, r4 101b8: eb001e5d bl 17b34 <fpc_read_text_float> 101bc: eb000e72 bl 13b8c <FPC_IOCHECK> 101c0: ed9d8b00 vldr d8, [sp] 101c4: e1a00004 mov r0, r4 101c8: eb001e4f bl 17b0c <FPC_READ_END> 101cc: eb000e6e bl 13b8c <FPC_IOCHECK> 101d0: eb001c6a bl 17380 <fpc_get_output> 101d4: e1a04000 mov r4, r0 101d8: e59f203c ldr r2, [pc, #60] ; 1021c <PASCALMAIN+0x90> 101dc: e3e01000 mvn r1, #0 101e0: e59f0038 ldr r0, [pc, #56] ; 10220 <PASCALMAIN+0x94> 101e4: ed900b00 vldr d0, [r0] 101e8: ee380b00 vadd.f64 d0, d8, d0 101ec: e1a03004 mov r3, r4 101f0: e3a00001 mov r0, #1 101f4: eb001d68 bl 1779c <fpc_write_text_float> 101f8: eb000e63 bl 13b8c <FPC_IOCHECK>
I can't get dynamic linking to work (and ppcarm itself is statically linked), but the binary embeds the correct program interpreter:
[root@calxeda-arm-soc-04 tmp]# strings -a /usr/bin/ppcarm | grep /lib/ld-linux /lib/ld-linux-armhf.so.3
How do you want to proceed? We have a hacked glibc in F26 and earlier which happens to run FPC softfloat binaries with the old program interpreter. I can restore that to F27 and rawhide if this helps to restore armhfp/EABIHF support, but maybe this is counterproductive because it obscures problems.
Can I bootstrap the newer 3.0 release using the fpc-2.6.2-4.fc20 build? If so I can deal with this.
On 09/14/2017 09:59 PM, Peter Robinson wrote:
How do you want to proceed? We have a hacked glibc in F26 and earlier which happens to run FPC softfloat binaries with the old program interpreter. I can restore that to F27 and rawhide if this helps to restore armhfp/EABIHF support, but maybe this is counterproductive because it obscures problems.
Can I bootstrap the newer 3.0 release using the fpc-2.6.2-4.fc20 build? If so I can deal with this.
I tried that, but I got this for the master branch:
ppcarm -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../arm -Fi../unix -Fiarm -FE. -FU/tmp/fpc/fpcbuild-3.0.2/fpcsrc/rtl/units/arm-linux -k"--build-id" -gl -darm -dRELEASE -Fi../objpas/sysutils ../unix/sysutils.pp syshelph.inc(40,31) Error: Identifier not found "Helper" syshelph.inc(40,31) Error: Error in type definition syshelph.inc(40,31) Error: Can't create unique type from this type syshelph.inc(40,31) Fatal: Syntax error, ";" expected but "FOR" found Fatal: Compilation aborted Makefile:3536: recipe for target 'sysutils.ppu' failed
fpc-3.0.0-1.fc24.armv7hl is able to build it, but has already switched to soft-float.
fpc-2.6.4-2.fc23.armv7hl is still okay, but fails to build in the same place. I can partially build fpc 3.0.0 with it, but that's where the ABI regression happens. The ABI regression is avoided if I delete the /lib/ld-linux.so.3 symbolic link first. However, that doesn't help with building with the regressed compilers because they have lost EABIHF support (they only support a single ABI variant).
Well, looking back at the history, I found this:
commit 62ea5a56cb91c1688d01a7e8df266af798632045 Author: Joost van der Sluis joost@cnoc.nl Date: Sat Jan 9 17:18:56 2016 +0100
Bootstrap ARM using cross-compiled armhl binaries, because the (patched) 2.6.4-ARM compiler in the repository is not able to compile the 3.0.0 release.
That probably explains the ABI regression. ppcarm found in the tarball has the wrong path for the program interpreter.
Florian
-
Florian Weimer -
Peter Robinson