Best approach for integrating a non-ARM toolchain
Opened this issue · 2 comments
I'm working on integrating a riscv32 toolchain so I can use bazel-embedded as the compiler configuration for the OpenTitan project (https://opentitan.org). It appears there are some incompatible flags between ARM and riscv32 gcc compilers.
Experimentally, I'm handling these flag differences with if
statements in toolchains/features/common/impl/gcc.bzl
and toolchains/features/embedded/impl/gcc.bzl
. This seems ugly to me and that it would be more appropriate to elevate some of the compiler flag selections to the platform or device configurations in platforms/BUILD
and/or devices/riscv32/riscv32.bzl
. (See lowRISC#1)
I'm creating this issue to solicit feedback on the best approach.
After digging in a bit more, it seems that the device struct defined in devices/device_config.bzl
might be the best way to specify architecture specific flags that would get passed to the toolchain feature functions in toolchains/features/{common,embedded}
.
I'm not quite sure if/how one might tie a toolchain with device config to a platform definition in platforms/BUILD
. The toolchains seem to be bound to the architecture by the cpu
constraint (via target_compatible_with
of native.toolchain
when the toolchains are registered). I'm curious if it makes sense to constrain on the platform as well? One could then link a device_config together with a platform definition and specify compiler/linker flags that you might want for your particular platform.
Sorry for the late reply. I've also been looking into this. I have been working on a complete rewrite of the toolchain suite using clang tools. Checkout bazel_rules_cc_toolchain which should support this better. The new approach allows you to swap out system libraries and sysroots fairly easily. I haven't added arm-none-eabi yet but that is eventually the goal.
The biggest challenge I am running into so far with risc-v is the lack of precompiled binaries for system libs e.g. libc, libc++ etc. ARM ships a distribution of GCC alongside pre-compiled and configured libc and libc++ implementations. This makes creating a toolchain suite a lot simpler.
If you have experience with risc-v toolchains more generally I'd be keen to collaborate on this.