[opensuse-buildservice] [RFC] Is there any plan to add ILP32 support for aarch64?
Hi, guys This is Bamvor Jian Zhang from Huawei OS team. Recently, I am working on enable the ILP32 support for arm64 based on the community work[kernel\_ilp32][glibc\_ilp32]. ILP32 is a method for running 32bit application on 64bit platform, such binary is elf32 with aarch64 assembly and is compiled by 64bit compiler. Refer the following table: \- | arm 32bit | arm64 ILP32 | arm64 LP64 ----------------|-------------|-------------|------------- instruction set | armv7-a | armv8-a | armv8-a int | 32bit | 32bit | 32bit long | 32bit | **32bit** | 64bit pointer | 32bit | **32bit** | 64bit x32 and n32 is the ILP32 ABI in x86\_64 and MIPS 64 respectively. Right now, more than 99% of LTP test cases is passed. And we get 2.6% to 7.9% performance improvement compare with aarch64 without any optimization or tuning. Base on these work, we are sure that ILP32 is worth to work on and we could feel more confident if more and more packages build and test. The obs seems the best way to build ilp32 packages, I wondering is there any document or guidance about how to add ILP32 to an architecture or how to add a new ABI to a new architecture? I got 4 commit about aarch64 in obs source code[openbuildservice] with "git log --grep aarch64": effc064 [backend] aarch64 workers can also build 32bit arm e0bd2e5 [api] add aarch64 to xml schema file b71ecfe [api] add aarch64 architecture 0c08cbe [backend] add aarch64 architecture But I still not puzzled about how to start. I also found some Linux32 definitions in obs source code[openbuildservice], does it mean the ilp32 is supported on the following architecture? src/backend/BSCando.pm: 'x86_64' => [ 'x86_64', 'i586:linux32', 'i686:linux32' ], src/backend/BSCando.pm: 'parisc64'=> [ 'hppa64', 'hppa:linux32' ], src/backend/BSCando.pm: 'ppc64' => [ 'ppc64le', 'ppc64', 'ppc:linux32' ], src/backend/BSCando.pm: 'ppc64p7' => [ 'ppc64le', 'ppc64p7', 'ppc:linux32' ], src/backend/BSCando.pm: 'ppc64le' => [ 'ppc64le', 'ppc64', 'ppc:linux32' ], src/backend/BSCando.pm: 's390x' => [ 's390x', 's390:linux32' ], src/backend/BSCando.pm: 'sparc64' => [ 'sparc64v', 'sparc64', 'sparcv9v', 'sparcv9', 'sparcv8:linux32', 'sparc:linux32' ], BTW: basically, add ilp32 support means that adding ilp32 support to kernel, gcc and glibc. And pass CC or CXX with additional -mabi=ilp32 to overwrite the default -mabi=lp64 when building the packages. regards bamvor [kernel\_ilp32] kernel ilp32 patch(v3): https://lkml.org/lkml/2014/9/3/704 [glibc\_ilp32] glibc ilp32 patch: https://sourceware.org/ml/libc-alpha/2014-10/msg00596.html [openbuildservice] https://github.com/openSUSE/open-build-service.git -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Monday 2015-01-26 10:30, Bamvor Jian Zhang wrote:
I got 4 commit about aarch64 in obs source code[openbuildservice] with "git log --grep aarch64": effc064 [backend] aarch64 workers can also build 32bit arm e0bd2e5 [api] add aarch64 to xml schema file b71ecfe [api] add aarch64 architecture 0c08cbe [backend] add aarch64 architecture
But I still not puzzled about how to start.
I also found some Linux32 definitions in obs source code[openbuildservice], does it mean the ilp32 is supported on the following architecture?
src/backend/BSCando.pm: 'x86_64' => [ 'x86_64', 'i586:linux32', 'i686:linux32' ], src/backend/BSCando.pm: 'sparc64' => [ 'sparc64v', 'sparc64', 'sparcv9v', 'sparcv9', 'sparcv8:linux32', 'sparc:linux32' ],
This table maps `uname -m` to packages that can be built (using :helper). Therefore, 'x86_64' => [ 'x86_64', 'x32', 'i586:linux32', ...] Similar for arm.
BTW: basically, add ilp32 support means that adding ilp32 support to kernel, gcc and glibc. And pass CC or CXX with additional -mabi=ilp32 to overwrite the default -mabi=lp64 when building the packages.
This is better done in /usr/lib/rpm/rpmrc: optflags: x86_64 -O2 -g -m64 -D_FORTIFY_SOURCE=2 ... optflags: x32 -O2 -g -mx32 -D_FORTIFY_SOURCE=2 ... which means rpm itself needs to be augmented first. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Good answer, thanks Jan, On Montag, 26. Januar 2015, 10:57:12 wrote Jan Engelhardt:
On Monday 2015-01-26 10:30, Bamvor Jian Zhang wrote:
I got 4 commit about aarch64 in obs source code[openbuildservice] with "git log --grep aarch64": effc064 [backend] aarch64 workers can also build 32bit arm e0bd2e5 [api] add aarch64 to xml schema file b71ecfe [api] add aarch64 architecture 0c08cbe [backend] add aarch64 architecture
But I still not puzzled about how to start.
I also found some Linux32 definitions in obs source code[openbuildservice], does it mean the ilp32 is supported on the following architecture?
src/backend/BSCando.pm: 'x86_64' => [ 'x86_64', 'i586:linux32', 'i686:linux32' ], src/backend/BSCando.pm: 'sparc64' => [ 'sparc64v', 'sparc64', 'sparcv9v', 'sparcv9', 'sparcv8:linux32', 'sparc:linux32' ],
This table maps `uname -m` to packages that can be built (using :helper). Therefore,
I just want to add here that this helper "linux32" needs to be available as binary to do the personality switch. I hope the aarch64 kernel supports this and you have such a binary doing the 64bit->32bit personality switch. If not, you can go the ppc64le way, where the kernel launched inside the VM is doing the switch (from big to little endian in this case). Check our kernel-obs-build package for details how to provide such a kernel.
'x86_64' => [ 'x86_64', 'x32', 'i586:linux32', ...]
Similar for arm.
BTW: basically, add ilp32 support means that adding ilp32 support to kernel, gcc and glibc. And pass CC or CXX with additional -mabi=ilp32 to overwrite the default -mabi=lp64 when building the packages.
This is better done in /usr/lib/rpm/rpmrc:
optflags: x86_64 -O2 -g -m64 -D_FORTIFY_SOURCE=2 ... optflags: x32 -O2 -g -mx32 -D_FORTIFY_SOURCE=2 ...
which means rpm itself needs to be augmented first.
Or even better, you have a gcc.rpm for aarch32 architecture which has this default already? Do you need a aarch32 architecture definition for your builds in OBS? I can submit one to git master if needed ... -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Adrian Schröter <adrian@suse.de> writes:
Good answer, thanks Jan,
On Montag, 26. Januar 2015, 10:57:12 wrote Jan Engelhardt:
On Monday 2015-01-26 10:30, Bamvor Jian Zhang wrote:
I got 4 commit about aarch64 in obs source code[openbuildservice] with "git log --grep aarch64": effc064 [backend] aarch64 workers can also build 32bit arm e0bd2e5 [api] add aarch64 to xml schema file b71ecfe [api] add aarch64 architecture 0c08cbe [backend] add aarch64 architecture
But I still not puzzled about how to start.
I also found some Linux32 definitions in obs source code[openbuildservice], does it mean the ilp32 is supported on the following architecture?
src/backend/BSCando.pm: 'x86_64' => [ 'x86_64', 'i586:linux32', 'i686:linux32' ], src/backend/BSCando.pm: 'sparc64' => [ 'sparc64v', 'sparc64', 'sparcv9v', 'sparcv9', 'sparcv8:linux32', 'sparc:linux32' ],
This table maps `uname -m` to packages that can be built (using :helper). Therefore,
I just want to add here that this helper "linux32" needs to be available as binary to do the personality switch. I hope the aarch64 kernel supports this and you have such a binary doing the 64bit->32bit personality switch.
linux32 (ie. personality(PER_LINUX32)) will switch the uname -m output from aarch64 to armv8l.
BTW: basically, add ilp32 support means that adding ilp32 support to kernel, gcc and glibc. And pass CC or CXX with additional -mabi=ilp32 to overwrite the default -mabi=lp64 when building the packages.
This is better done in /usr/lib/rpm/rpmrc:
optflags: x86_64 -O2 -g -m64 -D_FORTIFY_SOURCE=2 ... optflags: x32 -O2 -g -mx32 -D_FORTIFY_SOURCE=2 ...
which means rpm itself needs to be augmented first.
Or even better, you have a gcc.rpm for aarch32 architecture which has this default already?
Presumable a armv8l architecture will have a compiler that defaults to generating 32-bit (ILP32) code. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Monday 2015-01-26 11:05, Adrian Schröter wrote:
src/backend/BSCando.pm: 'sparc64' => [ 'sparc64v', 'sparc64', 'sparcv9v', 'sparcv9', 'sparcv8:linux32', 'sparc:linux32' ],
This table maps `uname -m` to packages that can be built (using :helper). Therefore,
I just want to add here that this helper "linux32" needs to be available as binary to do the personality switch. I hope the aarch64 kernel supports this and you have such a binary doing the 64bit->32bit personality switch.
The personality however must NOT be switched for x32/sparcv9/I32-on-64ish.
optflags: x86_64 -O2 -g -m64 -D_FORTIFY_SOURCE=2 ... optflags: x32 -O2 -g -mx32 -D_FORTIFY_SOURCE=2 ...
which means rpm itself needs to be augmented first.
Or even better, you have a gcc.rpm for aarch32 architecture which has this default already?
In case of x32 and sparcv9, our gcc(64bit) already can produce these, and is the one to use. The ILP32 ones work more like what ppc is to ppc64 than what i586 is to x86_64. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> writes:
The ILP32 ones work more like what ppc is to ppc64 than what i586 is to x86_64.
In which way are these two cases different? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Monday 2015-01-26 11:40, Andreas Schwab wrote:
Jan Engelhardt <jengelh@inai.de> writes:
The ILP32 ones work more like what ppc is to ppc64 than what i586 is to x86_64.
In which way are these two cases different?
Instruction and register sets. For example, the "addq" assembler instructions is not available to i586, while it is for x32 (and x86_64). -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> writes:
On Monday 2015-01-26 11:40, Andreas Schwab wrote:
Jan Engelhardt <jengelh@inai.de> writes:
The ILP32 ones work more like what ppc is to ppc64 than what i586 is to x86_64.
In which way are these two cases different?
Instruction and register sets. For example, the "addq" assembler instructions is not available to i586, while it is for x32 (and x86_64).
The same for ppc vs. ppc64. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Monday 2015-01-26 11:54, Andreas Schwab wrote:
Jan Engelhardt <jengelh@inai.de> writes:
On Monday 2015-01-26 11:40, Andreas Schwab wrote:
Jan Engelhardt <jengelh@inai.de> writes:
The ILP32 ones work more like what ppc is to ppc64 than what i586 is to x86_64.
In which way are these two cases different?
Instruction and register sets. For example, the "addq" assembler instructions is not available to i586, while it is for x32 (and x86_64).
The same for ppc vs. ppc64.
Eh? The 64-bit "STD" instruction can be used in an ELF32 file on a ppc64 system. This is possible because PPC does not (appear) to know different CPU modes. i586 however, is one. It has a different e_machine field in the ELF header, for one, causing the machine to exit Long Mode. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Jan Engelhardt <jengelh@inai.de> writes:
Eh? The 64-bit "STD" instruction can be used in an ELF32 file on a ppc64 system.
Nothing stops you from putting random instructions in a binary.
This is possible because PPC does not (appear) to know different CPU modes.
Read about the SF/CM bit in the MSR register.
i586 however, is one. It has a different e_machine field in the ELF header, for one,
Just like ppc. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Hi, guys With your help, I know that I should do the following step for ilp32 support for obs: 1. Add ilp32 support for kernel(community patches), gcc(only bugfix) and glibc(community patches). 2. Add ilp32 support for rpm and its configuration files. 3. Patch open-build-service according to Jan's reply. And, I still know nothing about the whole picture. I search on google and get some link in opensuse build service, it seems that it could not solve my quesiton[obs_add_build_target][obs_crossdevelop] BTW: do you think it is worth to put this on the GSoC 2015 proposals? [obs_add_build_target] https://en.opensuse.org/openSUSE:Build_Service_adding_build_targets [obs_crossdevelop] https://en.opensuse.org/openSUSE:Build_Service_Concept_CrossDevelopment regards bamvor -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
Hi, Jan On 2015/1/26 18:37, Jan Engelhardt wrote:
In case of x32 and sparcv9, our gcc(64bit) already can produce these, and is the one to use. Yes. our gcc could compile ilp32 on aarch64. But it failed in linking:
# cat main.c int main(){return 0;} # gcc-4.9 -mabi=ilp32 main.c -o main.ilp32 -nostdlib -nostartfiles -v --save-temps ... /usr/lib64/gcc/aarch64-suse-linux/4.9/collect2 -plugin /usr/lib64/gcc/aarch64-suse-linux/4.9/liblto_plugin.so -plugin-opt=/usr/lib64/gcc/aarch64-suse-linux/4.9/lto-wrapper -plugin-opt=-fresolution=main.res --build-id --eh-frame-hdr -dynamic-linker /lib/ld-linux-aarch64.so.1 -X -EL -maarch64linux -o main.ilp32 -L/usr/lib64/gcc/aarch64-suse-linux/4.9 -L/usr/lib64/gcc/aarch64-suse-linux/4.9/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/aarch64-suse-linux/4.9/../../../../aarch64-suse-linux/lib -L/usr/lib64/gcc/aarch64-suse-linux/4.9/../../.. main.o /usr/lib64/gcc/aarch64-suse-linux/4.9/../../../../aarch64-suse-linux/bin/ld: aarch64:ilp32 architecture of input file `main.o' is incompatible with aarch64 output /usr/lib64/gcc/aarch64-suse-linux/4.9/../../../../aarch64-suse-linux/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004000d4 collect2: error: ld returned 1 exit status It set the wrong ld.so(should be /lib/ld-linux-aarch64_ilp32.so.1), wrong elf type(should be -maarch64linux32). And it also required libilp32 library with compile without -nostdlib. I could make it right by forcing -maarch64linux32: /usr/lib64/gcc/aarch64-suse-linux/4.9/collect2 -plugin /usr/lib64/gcc/aarch64-suse-linux/4.9/liblto_plugin.so -plug in-opt=/usr/lib64/gcc/aarch64-suse-linux/4.9/lto-wrapper -plugin-opt=-fresolution=main.res --build-id --eh-frame-hdr -dynamic-linker /lib/ld-linux-aarc h64.so.1 -X -EL -maarch64linux32 -o main.ilp32 -L/usr/lib64/gcc/aarch64-suse-linux/4.9 -L/usr/lib64/gcc/aarch64-suse-linux/4.9/../../../../lib64 -L/lib /../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/aarch64-suse-linux/4.9/../../../../aarch64-suse-linux/lib -L/usr/lib64/gcc/aarch64-suse-linux/4.9/../../ .. main.o /usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400098 And the dynamic linker could be fixed by "gcc/config/aarch64/aarch64-linux.h": -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64%{mbig-endian:_be}%{mabi=ilp32:_ilp32}.so.1" +#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64%{mbig-endian:_be%{mabi=ilp32:_ilp32}}.so.1" But I do not know how to pass the -maarch64linux32 for linker. Any suggestion? Besides, when I install gcc49 on opensuse 13.2(aarch64), it reports the libgcc_s1 conflict. Could I force installing the libgcc_s1_4.9.0 and libgomp1-4.9.0(maybe and libitm)? :/ # zypper in gcc49 Loading repository data... Reading installed packages... Resolving package dependencies... Problem: gcc49-4.9.0+r211729-2.1.2.aarch64 requires libgcc_s1 >= 4.9.0+r211729-2.1.2, but this requirement cannot be provided uninstallable providers: libgcc_s1-gcc49-4.9.0+r211729-2.1.2.aarch64[openSUSE-13.2-repo-oss] Solution 1: Following actions will be done: deinstallation of libgcc_s1-4.8.3+r212056-2.2.1.aarch64 deinstallation of libgomp1-4.8.3+r212056-2.2.1.aarch64 Solution 2: do not install gcc49-4.9.0+r211729-2.1.2.aarch64 Solution 3: break gcc49-4.9.0+r211729-2.1.2.aarch64 by ignoring some of its dependencies
The ILP32 ones work more like what ppc is to ppc64 than what i586 is to x86_64. agree.
regards bamvor -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Tuesday 2015-01-27 12:03, Bamvor Jian Zhang wrote:
Yes. our gcc could compile ilp32 on aarch64. But it failed in linking:
# cat main.c int main(){return 0;} # gcc-4.9 -mabi=ilp32 main.c -o main.ilp32 -nostdlib -nostartfiles -v --save-temps
I would assume that -mabi is only used for compilation, not linking. For linking, -m32/-mx32/-m64 would be needed. What the proper flag for aarch is though, I know not. -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
2015-01-27 19:19 GMT+08:00 Jan Engelhardt <jengelh@inai.de>:
On Tuesday 2015-01-27 12:03, Bamvor Jian Zhang wrote:
Yes. our gcc could compile ilp32 on aarch64. But it failed in linking:
# cat main.c int main(){return 0;} # gcc-4.9 -mabi=ilp32 main.c -o main.ilp32 -nostdlib -nostartfiles -v --save-temps
I would assume that -mabi is only used for compilation, not linking. For linking, -m32/-mx32/-m64 would be needed. What the proper flag for aarch is though, I know not.
Thanks. hope I could find it out. regards bamvor
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On 2015/1/26 17:57, Jan Engelhardt wrote:
On Monday 2015-01-26 10:30, Bamvor Jian Zhang wrote:
I got 4 commit about aarch64 in obs source code[openbuildservice] with "git log --grep aarch64": effc064 [backend] aarch64 workers can also build 32bit arm e0bd2e5 [api] add aarch64 to xml schema file b71ecfe [api] add aarch64 architecture 0c08cbe [backend] add aarch64 architecture
But I still not puzzled about how to start.
I also found some Linux32 definitions in obs source code[openbuildservice], does it mean the ilp32 is supported on the following architecture?
src/backend/BSCando.pm: 'x86_64' => [ 'x86_64', 'i586:linux32', 'i686:linux32' ], src/backend/BSCando.pm: 'sparc64' => [ 'sparc64v', 'sparc64', 'sparcv9v', 'sparcv9', 'sparcv8:linux32', 'sparc:linux32' ],
This table maps `uname -m` to packages that can be built (using :helper). Therefore,
'x86_64' => [ 'x86_64', 'x32', 'i586:linux32', ...]
Similar for arm.
got it. thanks.
BTW: basically, add ilp32 support means that adding ilp32 support to kernel, gcc and glibc. And pass CC or CXX with additional -mabi=ilp32 to overwrite the default -mabi=lp64 when building the packages.
This is better done in /usr/lib/rpm/rpmrc:
optflags: x86_64 -O2 -g -m64 -D_FORTIFY_SOURCE=2 ... optflags: x32 -O2 -g -mx32 -D_FORTIFY_SOURCE=2 ...
which means rpm itself needs to be augmented first.
I am not familiar with rpm internal. I guess you suggest me that add ilp32 support for rpm first? Just like the x32 patch from H.J. Lu[1]? [1] https://sites.google.com/site/x32abi/x32-patches/rpm-4.11-x32-1.patch regards bamvor -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (5)
-
Adrian Schröter -
Andreas Schwab -
Bamvor Jian Zhang -
Bamvor Zhang -
Jan Engelhardt