Bug 595834 – sys-devel/clang: arm keywording (was: does not detect arm hardfloat)

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Felix Janda 2016-10-01 22:18:27 UTC]

This is a reboot of bug 510906.

gentoo uses for arm target triples of the form

arm-softfloat-linux-gnueabi
arm-hardfloat-linux-gnueabi

whereas most other distros use

arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf

instead.

With the latter targets, Clang correctly detects whether hardfloat
should be used or not, but for gentoo it does not, and defaults to
softfloat.

The 3.8.1/clang/musl-support.patch had a fix for this issue, which
has not been submitted upstream, and is not included in clang-3.9.0.


It might be good to think about changing the triple, though. I think
that rust has also problems with our triples.

[Comment 1 Michał Górny 2016-10-12 06:25:52 UTC]

CC-ing arm@ for the triples.

[Comment 2 Michał Górny 2016-10-12 06:28:20 UTC]

In the meantime, I'll work on supporting our creepy triples. It's still better than MIPS where our triples are completely unpredictable.

[Comment 3 Michał Górny 2016-10-12 06:48:33 UTC]

Created attachment 449958 [details, diff]
0001-Triple-Handle-Gentoo-arm-hardfloat-gnueabi-triples.patch

Could you test the attached patch, please? It's different approach than the one used by musl patch but I think it'd be more convenient to just normalize the triple in LLVM than to add its support everywhere.

[Comment 4 Felix Janda 2016-10-12 10:58:30 UTC]

Thanks for the patch. However I'm using armv7a-hardfloat-linux-musleabi...

[Comment 5 Felix Janda 2016-10-12 11:16:33 UTC]

Maybe let the patch append "hf" to Components[3] if Components[3] ends
with "eabi", and use parseEnvironment() to reparse the environment.

[Comment 6 Michał Górny 2016-10-12 14:50:14 UTC]

Created attachment 450002 [details, diff]
0001-Triple-Handle-Gentoo-arm-hardfloat-eabi-triples.patch

Try this one.

[Comment 7 Michał Górny 2016-10-12 14:52:07 UTC]

Created attachment 450004 [details, diff]
0001-Triple-Handle-Gentoo-arm-hardfloat-eabi-triples.patch (less context)

Sorry for the amount of context. This one's more suited to Gentoo and less suited for Phabricator ;-).

[Comment 8 Felix Janda 2016-10-13 01:09:17 UTC]

I've tested the patch with CHOST armv7a-hardfloat-linux-musleabi.
Running clang -v on a hello-world gives:

clang version 3.9.0 (tags/RELEASE_390/final)
Target: armv7a-hardfloat-linux-musleabihf
Thread model: posix
InstalledDir: /mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin
 "/mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/clang-3.9" -cc1 -triple armv7-hardfloat-linux-musleabihf -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name a.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu cortex-a8 -target-abi aapcs-linux -mfloat-abi hard -v -dwarf-column-info -debugger-tuning=gdb -resource-dir /mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/../lib/clang/3.9.0 -internal-isystem /usr/local/include -internal-isystem /mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/../lib/clang/3.9.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /mnt/tmpfs/tmp -ferror-limit 19 -fmessage-length 0 -fallow-half-arguments-and-returns -fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option -o /tmp/a-4f3460.o -x c a.c
clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target armv7a-hardfloat-linux-musleabihf
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/../lib/clang/3.9.0/include
 /usr/include
End of search list.
 "/usr/bin/ld" -X --eh-frame-hdr -m armelf_linux_eabi -dynamic-linker /lib/ld-musl-armv7ahf.so.1 -o a.out /usr/lib/../lib/crt1.o /usr/lib/../lib/crti.o crtbegin.o -L/mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/../lib -L/lib/../lib -L/usr/lib/../lib -L/mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/../lib -L/lib -L/usr/lib /tmp/a-4f3460.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o /usr/lib/../lib/crtn.o
/usr/bin/ld: cannot find crtbegin.o: No such file or directory
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find crtend.o: No such file or directory
clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation)


For comparison, here the same without the patch:

clang version 3.9.0 (tags/RELEASE_390/final)
Target: armv7a-hardfloat-linux-musleabi
Thread model: posix
InstalledDir: /mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin
Selected GCC installation: /usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0
 "/mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/clang-3.9" -cc1 -triple armv7-hardfloat-linux-musleabi -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name a.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu cortex-a8 -target-feature +soft-float-abi -target-abi aapcs-linux -mfloat-abi soft -v -dwarf-column-info -debugger-tuning=gdb -resource-dir /mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/../lib/clang/3.9.0 -internal-isystem /usr/local/include -internal-isystem /mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/../lib/clang/3.9.0/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir /mnt/tmpfs/tmp -ferror-limit 19 -fmessage-length 0 -fallow-half-arguments-and-returns -fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option -o /tmp/a-7dd1ec.o -x c a.c
clang -cc1 version 3.9.0 based upon LLVM 3.9.0 default target armv7a-hardfloat-linux-musleabi
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
 /mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/../lib/clang/3.9.0/include
 /usr/include
End of search list.
 "/usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/../../../../armv7a-hardfloat-linux-musleabi/bin/ld" -X --eh-frame-hdr -m armelf_linux_eabi -dynamic-linker /lib/ld-musl-armv7a.so.1 -o a.out /usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/../../../../lib/crt1.o /usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/../../../../lib/crti.o /usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/crtbegin.o -L/usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0 -L/usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/../../../../armv7a-hardfloat-linux-musleabi/lib/../lib -L/usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/../../../../lib -L/mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/../../../../armv7a-hardfloat-linux-musleabi/lib -L/usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/../../.. -L/mnt/a/tmp/portage/sys-devel/llvm-3.9.0/work/llvm-3.9.0.src-.arm/bin/../lib -L/lib -L/usr/lib /tmp/a-7dd1ec.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/crtend.o /usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/../../../../lib/crtn.o
/usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/../../../../armv7a-hardfloat-linux-musleabi/bin/ld: error: a.out uses VFP register arguments, /tmp/a-7dd1ec.o does not
/usr/lib/gcc/armv7a-hardfloat-linux-musleabi/6.2.0/../../../../armv7a-hardfloat-linux-musleabi/bin/ld: failed to merge target specific data of file /tmp/a-7dd1ec.o
clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation)


So it seems that clang uses the Target to find the GCC installation, and that does
not work anymore if we change the Target.

(Also a different bug in the musl support is visible: The dynamic
linker name should be "/lib/ld-musl-armhf.so.1".)

[Comment 9 Michał Górny 2016-10-13 07:41:34 UTC]

I see. Well, I guess I'm going to model the patch after the original musl patch then.

[Comment 10 Michał Górny 2016-10-17 16:34:24 UTC]

Created attachment 450580 [details, diff]
0001-Driver-Support-hardfloat-vendor-triples-used-by-Gent.patch (for clang)

So here's the third variant. I presume it doesn't need testing since it's what the old patch used to do. Nevertheless, feel free to give it a run.

I'll have to prepare a test case for it before I can submit it upstream though.

[Comment 11 Felix Janda 2016-10-17 17:20:31 UTC]

The hardfloat detection works fine with the new patch. (I luckily had
kept around the old build directory.) Thanks!

I've reported bug 597076 for the other issue observed in comment 8.

[Comment 12 Michał Górny 2016-12-02 17:59:25 UTC]

Created attachment 454920 [details, diff]
llvm: 0001-Triple-Support-parsing-Gentoo-ARM-triples-with-hardf.patch

[Comment 13 Michał Górny 2016-12-02 18:01:41 UTC]

Created attachment 454922 [details, diff]
clang: 0001-Driver-Improve-support-for-Gentoo-arm-hardfloat-eabi.patch

Here are two new patches based on upstream feedback. Could you test them, please? You need to apply the first one to LLVM, the second one to clang. I've added tests but I'd rather know for sure ;-).

The idea is that we shouldn't hack this around in clang but instead make LLVM recognize our hardfloat triples. The LLVM patch is enough to get things rolling with Gentoo triple; the clang patch additionally makes it possible to use a generic '-target arm-unknown-linux-gnueabihf'.

[Comment 14 Felix Janda 2016-12-03 01:54:29 UTC]

Thanks for the work with upstream!

The patches seem to work fine on armv7a-hardfloat-linux-musleabi.

[Comment 15 Michał Górny 2016-12-14 21:43:48 UTC]

*** Bug 597076 has been marked as a duplicate of this bug. ***

[Comment 16 Michał Górny 2016-12-14 21:46:23 UTC]

I've abandoned this pursuit. Fixing it upstream satisfactorily would require finding and fixing a lot of code. I certainly won't be able to find time for this, and I really see no reason to make clang much more complex just to support another stupid Gentoo divergence.

[Comment 17 Felix Janda 2018-02-11 13:09:24 UTC]

I just wanted to report that clang works fine here after changing my
CHOST to "armv7a-unknown-linux-musleabihf".

[Comment 18 Michał Górny 2018-09-08 06:30:08 UTC]

Could someone please confirm that it works fine with 17.0 profiles?  I suppose we can finally add keywords if that's solved.

[Comment 19 Felix Janda 2018-09-08 12:06:41 UTC]

works fine here on default/linux/arm/17.0/musl/armv7a/hardened profile.

[Comment 20 Larry the Git Cow 2018-10-18 07:18:02 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4237953cc2c2943cfa32fc4a3b860d3bd7f4c9ae

commit 4237953cc2c2943cfa32fc4a3b860d3bd7f4c9ae
Author:     Michał Górny <[e-mail]>
AuthorDate: 2018-10-18 06:37:37 +0000
Commit:     Michał Górny <[e-mail]>
CommitDate: 2018-10-18 07:17:54 +0000

    gentoo/profiles: Mask clang in 13.0 arm profiles
    
    Bug: https://bugs.gentoo.org/595834
    Signed-off-by: Michał Górny <[e-mail]>

 profiles/default/linux/arm/13.0/armv6j/package.mask   | 18 ++++++++++++++++++
 profiles/default/linux/arm/13.0/armv7a/package.mask   | 18 ++++++++++++++++++
 profiles/default/linux/musl/arm/armv7a/package.mask   | 18 ++++++++++++++++++
 profiles/default/linux/uclibc/arm/armv6j/package.mask | 18 ++++++++++++++++++
 profiles/default/linux/uclibc/arm/armv7a/package.mask | 18 ++++++++++++++++++
 5 files changed, 90 insertions(+)

[Comment 21 Michał Górny 2018-10-18 07:20:37 UTC]

@arm, please choose whichever of the packages you'd like to have and keyword them.  Please verify that clang compiles executables fine on hardfloat.  If you choose to drop some of the runtime deps, you'd need to package.use.mask specific flags on clang-runtime and libcxx* packages.

[Comment 22 Stabilization helper bot 2018-10-18 08:03:45 UTC]

An automated check of this bug failed - repoman reported dependency errors (126 lines truncated): 

> dependency.bad sys-libs/libcxx/libcxx-7.0.0.ebuild: DEPEND: ~arm(default/linux/arm/13.0) ['sys-libs/libcxxrt[libunwind=,static-libs?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']
> dependency.bad sys-libs/libcxx/libcxx-7.0.0.ebuild: RDEPEND: ~arm(default/linux/arm/13.0) ['sys-libs/libcxxrt[libunwind=,static-libs?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']
> dependency.bad sys-libs/libcxx/libcxx-7.0.0.ebuild: DEPEND: ~arm(default/linux/arm/17.0) ['sys-libs/libcxxrt[libunwind=,static-libs?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']
> dependency.bad sys-devel/clang-runtime/clang-runtime-7.0.0.ebuild: RDEPEND: ~arm(default/linux/arm/13.0) ['sys-libs/netbsd-csu[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']
> dependency.bad sys-devel/clang-runtime/clang-runtime-7.0.0.ebuild: RDEPEND: ~arm(default/linux/arm/17.0) ['sys-libs/netbsd-csu[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']
> dependency.badindev sys-devel/clang-runtime/clang-runtime-7.0.0.ebuild: RDEPEND: ~arm(default/linux/arm/13.0/armv4) ['sys-libs/netbsd-csu[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']

[Comment 23 tt_1 2018-10-18 08:06:21 UTC]

clang-6.0.1 works fine on a 17.0 profile with armv7-unknown-linux-gnueabihf 

clang-7.0.0 introduced -addrsig and turned it on by default. This produces warnings of not found sections during striping of static-libs (#667854) 

libcxxabi is a bit of a mess, it doesn't compile with gcc. One patch has been accepted upstream, but there are at least two more unsolved problems (#667450) 

If using clang/clang++ as compiler for libcxx{abi}, the compile passes. But I'm not aware of any consequences this may have at runtime. 

#667854 can be removed as a blocker if you're aiming for clang-6, in any case please ping me if you need cpu time.

[Comment 24 Stabilization helper bot 2018-10-18 17:03:40 UTC]

An automated check of this bug failed - repoman reported dependency errors (41 lines truncated): 

> dependency.bad sys-devel/clang-runtime/clang-runtime-7.0.0.ebuild: RDEPEND: ~arm(default/linux/arm/13.0) ['sys-libs/netbsd-csu[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']
> dependency.bad sys-devel/clang-runtime/clang-runtime-7.0.0.ebuild: RDEPEND: ~arm(default/linux/arm/17.0) ['sys-libs/netbsd-csu[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']
> dependency.badindev sys-devel/clang-runtime/clang-runtime-7.0.0.ebuild: RDEPEND: ~arm(default/linux/arm/13.0/armv4) ['sys-libs/netbsd-csu[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]']