apache
[BUG] `BUILTIN_COMPILER_RT` option broken
Description / Steps to reproduce the issue
So I'm not sure if this is expected (I haven't seen it documented, nor any other issues mentioning it) but there seems to be a lack of support for using compiler-rt, at least when doing a Makefile build. (I used GNU Make because cmake was throwing errors, but an examination of the build files suggests the problem occurs with either build system.)
Anyway, I'm building for a Raspberry Pi Pico 2 from the latest release on an Ubuntu system.
I'm trying to get a build working using a custom configuration (I've been running into a variety of ostensible incompatible config options) and something I wound up doing is setting the "Builtin toolchain support" option to BUILTIN_COMPILER_RT.
I'm pretty sure the selection of a Pico 2 target (though this problem does not seem to be limited thereto) in combination with this flag is all that's needed to trigger the building of compiler-rt and thereby reproduce this issue.
In short, I'm running into a variety of assembler errors (I'd ballpark around 8 or so) that seem to be due to the build system attempting to assemble .S files from compiler-rt incompatible with the target platform.
Examples:
compiler-rt/compiler-rt/lib/builtins/arm/adddf3vfp.S:24: Error: selected FPU does not support instruction -- 'vadd.f64 d6,d6,d7'compiler-rt/compiler-rt/lib/builtins/arm/chkstk.S:28: Error: lo register required -- 'sub r12,r12,#4096'compiler-rt/compiler-rt/lib/builtins/arm/chkstk.S:29: Error: instruction not supported in Thumb16 mode -- 'subs r5,r5,#4096'compiler-rt/compiler-rt/lib/builtins/arm/divdf3vfp.S:25: Error: selected FPU does not support instruction -- 'vdiv.f64 d5,d6,d7'
The architecture-related compiler flags being passed to arm-none-eabi-gcc (Ubuntu package gcc-arm-none-eabi version 15:14.2.rel1-1) seem appropriate for the Pico 2:
-mcmse -mlittle-endian -march=armv8-m.main+dsp -mtune=cortex-m33 -mfpu=fpv5-sp-d16 -mfloat-abi=softfp -mthumb.
Most relevant here, the sp in the value of the -mfpu flag accurately reflects the fact that the device's FPU is single-precision.
The cause seems clear when I compare libs/libbuiltin/compiler-rt/Make.defs to libs/libbuiltin/compiler-rt/compiler-rt/CMakeLists.txt (the latter coming from the upstream compiler-rt source):
Specifically the former just uses a $(wildcard ...) to glob all *.S files in the relevant source directory of compiler-rt.
https://github.com/apache/nuttx/blob/a00ac581c5fcde6162db21029ffe422110ebe7d3/libs/libbuiltin/compiler-rt/Make.defs#L88
Note: Its adjacent cmake equivalent seems to do the same (though I can't try it due to other issues I ran into):
https://github.com/apache/nuttx/blob/a00ac581c5fcde6162db21029ffe422110ebe7d3/libs/libbuiltin/compiler-rt/CMakeLists.txt#L84-L85
Meanwhile, the CMakeLists.txt in the upstream compiler-rt conditionally assembles source files based on the target platform.
For example, the chkstk.S assembly source file, where one of the errors I listed occurs, is only assembled if the target runs MingW:
https://github.com/llvm/llvm-project/blob/e19b7dc36bc047b9eb72078d034596be766da350/compiler-rt/lib/builtins/CMakeLists.txt#L522-L531
The files triggering rest of my errors are explicitly excluded if a compiler test indicates the FPU is not double-precision: https://github.com/llvm/llvm-project/blob/e19b7dc36bc047b9eb72078d034596be766da350/compiler-rt/lib/builtins/CMakeLists.txt#L796-L804 https://github.com/llvm/llvm-project/blob/e19b7dc36bc047b9eb72078d034596be766da350/compiler-rt/lib/builtins/CMakeLists.txt#L464-L483
Obviously these errors will cause the build process to fail. Excluding them seems to resolve the issue, as far as I can tell.
On which OS does this issue occur?
[OS: Linux]
What is the version of your OS?
Ubuntu 25.10 (Questing) / Kernel 6.17.0-6-generic / x86_64
NuttX Version
12.11.0
Issue Architecture
[Arch: x86_64], [Arch: arm]
Issue Area
[Area: Build System]
Host information
I believe I've identified the issue (the fact that libs/libbuiltin/compiler-rt/Make.defs compiles/assembles all source files, regardless of their compatibility with the target processor), so I'm pretty sure my specific host info, beyond my target device (mentioned above), is irrelevant.
Verification
- [x] I have verified before submitting the report.
Could you provide me with a .config file and the modified configuration so I can reproduce the problem locally and troubleshoot it? @mvastola
