LLVM Embedded Toolchains Working Group sync up

Community
10

2022-08-18 Multilib support, LLVM libc, libc++, 16-bit pointers

Participants

  1. Stephen Hines

  2. Stefan Granitz

  3. Simon Wallis

  4. Javid

  5. Michael Jones

  6. Peter Smith

  7. Siva Chandra

  8. Petr Hosek

  9. Nigel Perks

  10. Guillot Tony

  11. Prabhu Rajasekaran

  12. Mikhail Maltsev

  13. Volodymyr Turanskyy

Agenda

  • Multilib support
  • Libc
  • Libc++
  • 16-bit pointers

Discussion

Multilib support (Mikhail)

  • Toolchain class can be subclassed to provide required features.

  • There is a prototype of a plugin - each vendor can implement their own as needed.

  • The idea is to provide a way to load plugins that can match target triples and then implement required logic for multilib support for the target.

  • Next step - implement multilib selection.

  • Support for plugins requires only a small amount of code. Some files may need to be moved out of the implementation folder to make them part of public API.

  • An alternative would be to create a DSL like GCC spec files to transform command line options into library selection options. May need rather tricky logic, thus difficult to design and implement reasonable DSL.

  • Q (Petr): multilib class exists in LLVM - can it be extended? A: This is enough, but each vendor may need to implement their own specific logic. There is no multilib implementation for baremetal Arm now. It may be beneficial to keep this vendor specific code downstream.

  • Q (Petr): what about performance and security of plugin implementations? A: could be an issue, indeed.

  • Peter: plugin DLLs on Windows may be tricky to maintain too.

  • Q (Peter): Would a data driven DSL/config file cover the need, rather than a complex executable DSL? Different targets may need different sets of command line options to take into account.

  • Q (Petr): Should we investigate support for actual (or subset of) GCC spec files? Minimal implementation may be small and may be easier for people to migrate from GCC. Was it not supported on purpose, based on LLVM design philosophy? Yes, there was such a discussion years ago, does it make sense to reopen the discussion again? Config files are becoming more configurable now too, so this may support the argument to look again into spec files support.

  • Mikhail will have a look into spec files option as well as a simple DSL to describe multilibs. Would be good to start a thread on Discourse - we may start with a high level options overview to decide on the direction (without spending much time for multiple prototypes upfront).

  • Q Mikhail: Is it possible to build runtimes with cmake by getting the list of multilibs from clang (like GCC does)? Petr: Not now. Cmake and clang info may not match now - no way to enforce. Fuchsia team is starting to look into this.

Libc

  • Peter: startup code write up on Discourse - to do an informative analysis of approaches.

  • Siva: no much news for now.

  • Stefan: Q: want to use libc for embedded JIT. Can it be compiled for PIC (position independent code)? Siva: yes, PIC should be possible as there should not be anything preventing PIC, otherwise please report an issue.

  • Stefan: The idea is to compile only required functions with JIT and load them on the embedded target. Compiled and linked on the host, then transferred to a device and executed there.

  • Q: Is libc designed with static build in mind or incremental (per function basis) builds are possible? A: If a given function does not depend on global data, that should be possible.

  • Note that there are different PIC models, e.g. PIE and actually PIC. PIE requires data to be at a specific place. There are models when there is a register with base for all the data.

  • Libc does not use virtual functions thus does not have an issue with vtables that needs to be addressed in a PIC model.

  • Libc build instructions are provided at the llvm site: Building libc using the runtimes build setup — The LLVM C Library

Libc++

  • Three main points from last time: building without particular subset of features, code size optimized versions of some features, source vs binary distributions.

  • Would be interesting to have an overview of Embedded C++ Libraries - what special features do they provide and which of them may be relevant to libc++.

16-bit pointers?

  • Q Petr: Armv6 M0+ has 256k addresses only, but requires full pointers that use a lot of space - is it possible to use 16 bit pointers?

  • Peter: No, such an approach can only work for M0+ since even M3 can use megabytes of RAM. One advice is to put all global data into a static struct so that the compiler uses relative addresses.

  • LTO may be an option, however LTO does not play well with section placement in embedded.

  • Literal pool merging can save a bit of size as well.

  • LTO can be a good future topic, it would be nice to invite someone who works on LTO and ThinLTO. Qulcomm did a relevant presentation a few years ago.