We’ve not received any submissions as yet. Replying with some ideas to seed the discussion. If you don’t want to commit, or just float an idea or express interest then feel free to respond on this thread. I’ll unfortunately not be able to attend in person this year, I’ve posted what I would have wanted to discuss, and would be happy to write some slides if there’s any interest in the topic.
Embedded Position Independent Code
For small bare-metal systems that run code out of flash, don’t have an MMU and have limited RAM, the traditional PIC/PIE model isn’t ideal. Instead of pc-relative addressing that requires code and data to be rigidly-relative, base-relative addressing permits independent relocation of code and data.
There is quite a large design space for code-models, each with some design trade-offs in efficiency, flexibility, portability (GCC support) and implementation-complexity. As a community we likely cannot support all of them, is there a consensus (per-target) on what should be supported.
On ARM, we have 3 major options that are already specified and implemented by a toolchain:
- ROPI/RWPI (no support for C++ or Rust)
-mno-pic-data-is-text-relative (GCC option), access code and data via a base-relative GOT.-fdpic (GCC option), extension of `-mno-pic-data-is-text-relative to shared-libraries (multiple bases).
On ARM our current preference is to implement support for the GCC option -mno-pic-data-is-text-relative rather than try and extend ROPI/RWPI (which suffers from the problem of unknown RO promotion to RW in a different TU, see ePIC proposal for RISCV below).
On RISCV, there have been proposals but no firm acceptance of an embedded code-model. These vary from adaptations of ARM options like -fdpic to ePIC Proposal for RISC-V Embedded PIC (ePIC) specification by luismarques · Pull Request #343 · riscv-non-isa/riscv-elf-psabi-doc · GitHub which is ROPI/RWPI like, but can support C++ and Rust. In theory this could be adapted to ARM to extend ROPI/RWPI.
RTOS or embedded linux.
If you had access to a low-power, relatively low resource CPU, but it did have an MMU, would you choose to run embedded linux for simplified software development, or would you prefer a traditional RTOS?
Arm’s most recent IoT CPUs have taken the form of a small AArch64 (https://newsroom.arm.com/blog/introducing-arm-cortex-a320-cpu) combined with a NPU rather than a high-end M profile CPU like a Cortex-M85. These AArch64 CPUs have an MMU and are capable of running embedded Linux as well as the more traditional RTOS like FreeRTOS or Zephyr. I selfishly would like to know how much interest there is bare-metal (RTOS) AArch64 on these devices.
Upstream bare-metal buildbots/precommit including llvm-libc and libc++
- We have an Arm v7m precommit buildbot for libc++. However that has support for atomics. Would be useful to have an Arm/RISCV precommit that does not have any synchronisation instructions to catch any atomics regressions in code or tests.
- Big endian build bot for llvm-libc, although this may end up catching more big-endian code-generation problems than library problems.
- Bare-metal configurations to catch uses of unguarded POSIX features in tests.
Previous topics that are still of interest
- Linker scripts and (thin)LTO.
- Compiling llvm-libc as part of the project.
- Multilib for clang resource directory.