[CFP] The LLVM embedded toolchain for Arm

[Peter Smith]

Title

The LLVM embedded toolchain for Arm

Author

Peter Smith, [e-mail] Arm

Distribution

A LLVM based toolchain for bare-metal embedded systems, initially focused on Cortex-M devices.

Abstract (optional)

For many years the GNU Arm Embedded toolchain has provided an open-source toolchain targeting embedded systems. The LLVM Embedded toolchain for Arm is a new open-source project with the goal of providing an LLVM based equivalent to the GNU Embedded toolchain. We would like the LLVM Embedded toolchain to lower the bar to entry of using LLVM in Embedded systems development. The project itself is a set of build scripts that combines tools and libraries from the llvm-project with the Newlib C-library to build the Toolchain from source. With the sample linker scripts it is simple to build and run a simple example that runs on the QEMU emulator. We have used, with a small enhancement, clang config files to approximate multilib and specs files for some hardware configurations. While sufficient for simple examples this will not scale well to the amount of Arm platforms that the GNU Arm Embedded Toolchain is able to support.

What's unique about the environment you package LLVM for? (optional)

The toolchain targets resource constrained devices in a freestanding environment. Targets need builds of libraries and custom linker scripts to match the memory model of the end device.

What makes your distribution of LLVM unique? (optional)

Packaging the LLVM tools and libraries with the newlib C library, with some built in configurations for common Cortex-M devices.

What might others learn from your experience? (optional)

Using configuration files in anger.
Using the bare-metal driver.
Integrating newlib

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

Some areas that the toolchain needs to improve that we'd like to work with the community on.

• Implementing multilib support in a way that can be upstreamed without hardcoding a library structure.
• Handling configuration choices that the GNU Embedded toolchain uses GCC specs files for (semihosting, non-semihosting etc).
• Supporting and testing more variants of compiler-rt for embedded A, R and M profile Arm CPUs.
• Implementing CI for a toolchain targeting microcontrollers. Ideally in a form that can report to the LLVM Community. For example, build-bots that cross-compile compiler-rt and run tests in emulators.

---

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

[Nick Desaulniers (paternity leave)]

Thanks for taking the time to write up a CFP; we'd be overjoyed to have you present at LLVM Distributors Conf 2021! If you still plan on presenting, this is a reminder to get started on your slides for next week. Once they're done, we will contact you about submitting a PDF of your slides as either a pull request to this repository or via email to the organizer. We hope to have a schedule finalized by EOW; we may iterate on the schedule based on whether presenters have conflicts. Please keep this issue open for attendees to ask questions, or close this issue if you no longer plan on attending. Reminder to keep your talk concise (15 minutes); we wont be doing time for questions in order to fit as much content as possible. Attendees should ask questions here in this github issue.

Using configuration files in anger.

lol!

Integrating newlib

Cool! I've been trying to figure out how to link clang against musl in ClangBuiltLinux/tc-build#151; I'm sure you're talk will be informative!

[Jessica Clarke]

Some of Arm's firmware projects, last I checked (SCP firmware in this case), require a GCC in order to locate a newlib sysroot and libgcc CRT files, meaning Clang isn't a first-class citizen and only worth using if you specifically want Clang's codegen, which causes us pain when we need to build firmware, since all our toolchains are pure LLVM. Is one of the goals of this project to render LLVM a first-class citizen for things like SCP firmware so you don't also need a whole GCC toolchain on the side, or is that out of scope and up to someone else to build on this work to achieve?

[Peter Smith]

Some of Arm's firmware projects, last I checked (SCP firmware in this case), require a GCC in order to locate a newlib sysroot and libgcc CRT files, meaning Clang isn't a first-class citizen and only worth using if you specifically want Clang's codegen, which causes us pain when we need to build firmware, since all our toolchains are pure LLVM. Is one of the goals of this project to render LLVM a first-class citizen for things like SCP firmware so you don't also need a whole GCC toolchain on the side, or is that out of scope and up to someone else to build on this work to achieve?

At the moment the goal is to have something that is similar in scope to the GNU RM Toolchain https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm including binary releases, particularly for Windows. This package would include the same kind of newlib and CRT files.

Whether the Arm internal teams pick this up as an alternative to GCC for projects like firmware will be up to them. My guess is that if the toolchain is compatible enough with GNU RM Toolchain that porting is easy then it will happen, if they have to do quite a bit of work without much payback probably not.

Will try and touch on this for the talk.