Summary: | cross-arm-none-eabi/newlib-4.3.0.20230120: build failed with <=gcc-11 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Vitaliy Perekhovy <feriman> |
Component: | Current packages | Assignee: | Luca Barbato <lu_zero> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugzilla, fatzer2, sam, toolchain, vapier, victor.donascimento |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://sourceware.org/pipermail/newlib/2022/020035.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Build log |
Description
Vitaliy Perekhovy
2023-01-21 11:06:53 UTC
Created attachment 848909 [details]
Build log
I can confirm the issue It seems to be a newlib issue, caused by a recent commit[1]. I suspect the macro-definitions tests around `vstm`/vldm` are incorrect... probably there supposed to be AND (`#if defined __ARM_FP && defined __ARM_FEATURE_MVE`) rather than OR (`||`)... though I'm not absolutely positive about that... it might be there supposed to be some `#else` in case `__ARM_FEATURE_MVE` is undefined (and as I suppose in such case the instruction are unavailable)... [1]: https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;f=newlib/libc/machine/arm/setjmp.S;h=15ad816dddf836def06cd0330ec0efa9ce50e5bf it builds fine for me with: cross-arm-eabi/binutils-2.39-r4 cross-arm-eabi/gcc-12.2.1_p20221231 cross-arm-eabi/newlib-4.3.0.20230120 what version of tools are you using ? (In reply to SpanKY from comment #4) > it builds fine for me with: > cross-arm-eabi/binutils-2.39-r4 > cross-arm-eabi/gcc-12.2.1_p20221231 > cross-arm-eabi/newlib-4.3.0.20230120 > > what version of tools are you using ? cross-arm-none-eabi/gcc-11.3.1_p20221209 cross-arm-none-eabi/binutils-2.39-r4 sys-devel/gcc-11.3.1_p20221223 (amd64 host) cross-arm-none-eabi/newlib-4.3.0.20230120 (fail, as for the bug) cross-arm-none-eabi/newlib-4.2.0.20211231 (compiles fine) Builds fine with cross-arm-none-eabi/gcc-12.2.1_p20221231 for me as well... So it seems to me it's a gcc-11 issue... Ok... I've poked it a bit more... here is what I've boiled it down to: gcc<12 (at least since 8) with flags like `-march=armv5te+fp -mfloat-abi=softfp` will refuse to compile arm FPU assembler instructions unless explicitly given an `-mfpu=auto` flag... That's only an issue for ASM code... C sources are unaffected because when assembled explicit `.fpu vfp` directive is added to the output... I failed to found any discussion/bugs/commits regarding that issue in gcc. I'm not sure how properly fix/workaround the issue... The simplest IMHO would be to nail newlib-4.3.0.20230120 to gcc-12+ on arm... Also I've managed to workaround it setting CCASFLAGS="-mfpu=auto" env var, though it's a bit of a dirty way to do it... PS: As of my previous idea about incorrect preprocessor macros: I was wrong. (In reply to Fat-Zer from comment #7) there is no way to do arch-specific DEPENDs i don't think upstream intended to make this requirement, and in general doesn't want to force recent versions of gcc. i can point out the problem on the patch and see what they say. (In reply to SpanKY from comment #9) > (In reply to Fat-Zer from comment #7) > > there is no way to do arch-specific DEPENDs Yeah... I was thinking we can die on pkg-setup like it's done for msp430/bug #717610... or if a failure sounds too much we can at least print a stern warning... > i don't think upstream intended to make this requirement, and in general doesn't want to force recent versions of gcc. i can point out the problem on the patch and see what they say. sure they don't... it looks like a gcc quirk... I've now proposed a Newlib patch to address the issue: https://sourceware.org/pipermail/newlib/2023/020154.html I've tested it going as far back as GCC 10.1 and I get a successful build with it, so I hope this serves as an adequate solution. (In reply to Victor Do Nascimento from comment #11) > I've now proposed a Newlib patch to address the issue: > > https://sourceware.org/pipermail/newlib/2023/020154.html > > I've tested it going as far back as GCC 10.1 and I get a successful build > with it, so I hope this serves as an adequate solution. Are you sure hardcoding an .fpu directive is safe enough for people targeting a different FPU and/or explicitly specifying it during build? I don't know that much about arm FPUs and how diverse they and their instruction sets are, so I'm a bit concern that there might be some build breakages (or even generation of malformed binaries) in such cases... though it might be alright... (In reply to Fat-Zer from comment #12) > (In reply to Victor Do Nascimento from comment #11) > > I've now proposed a Newlib patch to address the issue: > > > > https://sourceware.org/pipermail/newlib/2023/020154.html > > > > I've tested it going as far back as GCC 10.1 and I get a successful build > > with it, so I hope this serves as an adequate solution. > > Are you sure hardcoding an .fpu directive is safe enough for people > targeting a different FPU and/or explicitly specifying it during build? I > don't know that much about arm FPUs and how diverse they and their > instruction sets are, so I'm a bit concern that there might be some build > breakages (or even generation of malformed binaries) in such cases... though > it might be alright... If you look at the FPU-related instructions used in the file in question (setjmp.S), you'll see we do very little w/ the FPUs. The only operations concerned are those saving register values to memory and restoring them some time later using vstm and vldm. Insofar as the encodings for these instructions go, if you look at the ARM Architectural Reference Manuals, you'll see that the The encoding of an FP extension register load or store instructions makes no reference to the FPU used and is therefore invariant over the FPU choice. When it comes to linking, we need to be careful over the build attributes which get added to the resulting object as a result of or `.fpu name' choice. `.fpu vfpxd' seems to be a type of "lowest-common denominator" allowing us greatest flexibility when linking. From what I understand, vfpxd corresponds to FPU_ARCH_VFP_V1xD in the assembler, which is VFPv1 w/o support for doubles. We're not adding any attribute to our assembled setjmp/longjump functions which would suggest they require any architectural feature that vfp/mve targets can't provide, such that whatever target we're compiling for we shouldn't experience any linking difficulty. The now-committed fix to the issue also adds `.arch_extension mve' to the assembly file whenever we target MVE, hopefully covering all our bases. (In reply to Victor Do Nascimento from comment #13) > ... Thanks for the explanation, everything you say sounds legit... For the record, I was voicing my concern just because of a doubt (which I've supposed was reasonable enough); before posting I was inclining to the same conclusions you have listed, but I wasn't sure enough... PS: As for now, I think, the right resolution for the Gentoo bug (if my opinion worths anything) would be to backport the patch. Thanks for the feedback, I'm glad my reasoning seems reasonable! I will chase the Newlib maintainers about having the patch backported to newlib-4.3. A new snapshot of Newlib can be made, which would include the fix for this bug. The maintainers are waiting on the fix of a different unrelated issue so that the new snapshot can kill two birds in one stone. How urgent is the backport? Depending on the timeframe you've got in mind, I can liaise with the relevant parties in search of a satisfactory solution for everyone. (In reply to Victor Do Nascimento from comment #16) > A new snapshot of Newlib can be made, which would include the fix for this > bug. > > The maintainers are waiting on the fix of a different unrelated issue so > that the new snapshot can kill two birds in one stone. Any idea how that issue is going? We can wait if it's a little bit longer, but I wouldn't want to wait months either, I suppose. > > How urgent is the backport? Depending on the timeframe you've got in mind, I > can liaise with the relevant parties in search of a satisfactory solution > for everyone. Thank you. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1d2ff0e8d3c0e012ed57743adb869797782f1a26 commit 1d2ff0e8d3c0e012ed57743adb869797782f1a26 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-06-17 02:58:40 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-06-17 02:58:41 +0000 sys-libs/newlib: backport arm setjmp fix It looked like a new upstream release/snapshot was going to be made so I'd forgot about it, but got reminded of this today, so let's backport the patch. Closes: https://bugs.gentoo.org/891589 Signed-off-by: Sam James <sam@gentoo.org> ...0120-libc-arm-setjmp-gcc-backwards-compat.patch | 57 ++++++++ sys-libs/newlib/newlib-4.3.0.20230120-r2.ebuild | 154 +++++++++++++++++++++ 2 files changed, 211 insertions(+) |