Merging RISCVToolChain and BareMetal toolchains

Clang Frontend
,
1

I recently discovered that we have two RISC-V toolchain classes in Clang that are intended to support baremetal development:

  1. RISCVToolChain is used when an existing GCC installation is present.
  2. BareMetal is used otherwise.

I think this creates an unnecessary maintenance overhead and increases confusion as evidenced by [clang] Enable --gcc-install-dir for RISCV baremetal toolchains by mihailo-stojanovic · Pull Request #71803 · llvm/llvm-project · GitHub. I don’t think that support for using an existing GCC installation is RISC-V specific and would be also beneficial to other targets supported by the BareMetal toolchain.

I would like to propose extending the BareMetal toolchain to support using an existing GCC installation, and then deprecating and removing the RISCVToolChain.

1 Like
LLVM Embedded Toolchains Working Group sync up
LLVM Weekly - #519, December 11th 2023
2

On a similar note I wondered why there is CSKYToolChain which from reading the initial commit ([Clang][CSKY] Add the CSKY target and compiler driver · llvm/llvm-project@97e4960 · GitHub) just sounds like a typical Linux on CSKY Toolchain that could be merged into Linux.cpp/Gnu.cpp and BareMetal support.

3

I can’t speak for the RISCV toolchain itself, would very much like to see the functionality in the BareMetal toolchain so all targets that support it can benefit.

4

This sounds fantastic to me.

5

Hi @petrhosek, I wanted to know if you are still planning to work on merging these toolchain objects and retain only the BareMetal toolchain.

LLVM Embedded Toolchains Working Group sync up
6

I have posted an initial draft patch for this issue: [RISCV] Merging RISCVToolChain and BareMetal toolchains by quic-garvgupt · Pull Request #118809 · llvm/llvm-project · GitHub. Please take a look and provide any feedback or comments.

7

Hiya, we recently encountered a notable breakage in ChromiumOS caused by changes associated with this RFC: Reland [Driver] Add support for crtbegin.o, crtend.o and libgloss lib to BareMetal toolchain object by quic-garvgupt · Pull Request #144649 · llvm/llvm-project · GitHub

Specifically, our toolchain now detects (incorrectly) that we are a “GCC Adjacent” toolchain during armv7m baremetal builds. We weren’t able to correctly work around this locally, so we had to make some local driver extensions to revert to the old behaviour by default. https://chromium-review.git.corp.google.com/c/external/github.com/llvm/llvm-project/+/7793991

We (the ChromeOS LLVM Toolchain at Google) would like to propose a similar (perhaps less-experimental and more formal) upstream change. That is, checking to see whether we are GCC-Adjacent in the first place is opt-in behaviour, configured by flags passed to Clang rather than the default of baremetal.

8

This logic was introduced before the --cstdlib option, now that we have this option we should be able to use it to also select crtbegin.o, crtend.o and -lgloss.

9

Oh interesting! So the gccadjacent detection work here is redundant with –cstdlib? To be clear, we don’t have crtbegin.o or crtend.o or libgloss, but we do use glibc. It’s just auto-detecting that we do incorrectly because another toolchain outside of /usr/armv7m-none-eabi has crt0.o.