I’m suggesting the following for the description of the event. Will be sending this out towards 6:00pm UK time. Happy to incorporate any feedback.
I’m proposing half a day and < 25 attendees.
Short 1 paragraph description that describes to attendees what they can expect by attending.
Embedded systems software, which for the purposes of the workshop we’ll define as ranging from a no-operating system microcontroller project, to embedded linux, has some requirements that are different from userspace software that runs on top of an OS. The purpose of the workshop is to focus on the embedded specific requirements and coming up with an approach for addressing these in the open-source llvm-project. The focus will be on sharing knowledge of downstream solutions and discussing requirements and design of upstream features rather than a tutorial for how to build a toolchain for embedded systems.
Detailed description or agenda of the workshop
We haven’t got a detailed agenda confirmed. Our proposed list of topics
Using LTO for embedded development.
LTO is seen as a strength of the llvm-project, many of which should benefit embedded systems. However getting it working on an embedded project is too complex for many users, particularly when linker scripts are involved. There have been two LLVM dev meeting presentations on downstream solutions for how to interact with linker scripts 2022 LLVM Dev Mtg: Link-Time Attributes for LTO: Incorporating linker knowledge into the LTO... - YouTube and 2017 LLVM Developers’ Meeting: T. Edler Von Koch “Bringing link-time optimization to the ... ” - YouTube . We would like to agree on a design for getting this upstream.
Instrumentation
The existing implementation of the profiling runtime in compiler-rt won’t build for many embedded systems due to dependencies on the OS. There is scope for a stripped down runtime that can build for an embedded system. To get to this point some refactoring will be needed.
Embedded systems are often used in projects with functional safety requirements. A particular form of code-coverage called MC-DC is required for some safety integrity levels. There is a patch set in upstream review, if that hasn’t landed by the time of the workshop it can be discussed.
Optimizing for code size
When resources are limited small code size is often more important than highest performance. For the purposes of the workshop we are likely to concentrate on higher-level features such as the outliner than individual back-end optimizations.
Much recent work has gone into thin-LTO and performance, whereas embedded projects tend to be small enough to make use out of traditional whole program and the size reduction features that LTO offers without the scaling problems. Finding a way forward for a LTO for smallest code-size is a topic for discussion.
This topic has some overlap with the attempts to lower code-size for mobile applications, although the features used for mobile development may require code-generation work and that may not be available on embedded targets.
Embedded Linker features and diagnostics
Embedded systems often have complex memory maps which require complex linker scripts that are easy to get wrong. Many proprietary toolchains have additional features such as data compression, advanced overlay support, and automatic distribution of sections across memory regions. It would be great to get these features implemented in upstream linkers such as LLD and GNU ld. The major blocker is often justification for the additional implementation complexity.
Extra complex linker scripts are often hard to debug. There is scope for additional tracing and diagnostics, particularly machine readable output or GNU compatible output.
LLVM libc and libc++ for embedded systems
There aren’t many open-source C libraries suitable for embedded systems with newlib and lately picolibc as the main choices. LLVM libc would like to scale down to embedded systems. We would like to discuss experiences developers have with LLVM libc and gather requirements, such as the interface to heap allocation, that LLVM libc would need to be the default choice for embedded toolchains based on LLVM.
C++ use in embedded systems is on the rise, particulary in the automotive area with the advent of Autosar Adaptive. A large fraction of the C++ standard library as implemented by libc++ can be used by embdedded systems by excluding areas that depend on OS support such as the filesystem. Many limited file IO can be done, such as using the serial port or semihosting. There is an opportunity to come up with a shared view of what libc++ and libc++abi configuration options would be useful to support, and how we can provide buildbot support for them.