[fedora-arm] armhfp bootstrap needed for fpc

Discussion:

Florian Weimer

2017-09-14 19:11:22 UTC

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
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@li

Peter Robinson

2017-09-14 19:31:14 UTC

Permalink

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?
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
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send

Florian Weimer

2017-09-14 19:51:37 UTC

Permalink

Post by Peter Robinson

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:

[***@calxeda-arm-soc-04 tmp]# cat t.pas
var i: real;

begin
Read (i);
WriteLn (i + 3.0);
end.
[***@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
[***@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:

[***@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
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscrib

Peter Robinson

2017-09-14 19:59:28 UTC

Permalink

Post by Florian Weimer

Post by Peter Robinson

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

var i: real;
begin
Read (i);
WriteLn (i + 3.0);
end.
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
head -n 30
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
/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.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraprojec

Florian Weimer

2017-09-14 20:58:33 UTC

Permalink

Post by Peter Robinson

Post by Florian Weimer
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 <***@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
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fed