LLVM Embedded Toolchains Working Group sync up

Community
13

2022-10-13: libc++, multilib followup

Participants

  1. Siva Chandra

  2. Simon Wallis

  3. Tue Ly

  4. Michael Jones

  5. Nigel Perks

  6. David Spickett

  7. Pirama

  8. Petr Hosek

  9. Peter Smith

  10. Volodymyr Turanskyy

Agenda

  1. Any preparation for the LLVM Dev Meeting (The LLVM Compiler Infrastructure Project Nov 8-9, 2022) round table.
    Reminder: there will be no sync up call in November because of LLVM Dev Meeting happening at the same time.

  2. LLD features for embedded development.

  3. Next steps for the libc++ discussion related to embedded use cases.

  4. Any follow up on the previous topics on libc.

Discussion

LLVM Dev Meeting round table

  • David and Kristof from Arm will attend the LLVM Dev Meeting.

  • No specific preparation for the round table discussed.

LLD embedded features (Peter)

  • Arm team started working on some feature in LLD for embedded use cases:

    • Big endian was supported for AArch64, we are adding support for Arm for completeness.

    • CMSE (Cortex-M Security Extensions, TrustZone M) support for linking code for secure and non-secure worlds.

  • Patches will be upstream soon, reviews are welcome.

libc++ for embedded (Volodymyr)

Looking at existing libraries and guidance targeting embedded use cases, the following are some of the most usual configuration options/needs:

  1. Cross compilation.
  2. Cross testing.
  3. No exceptions.
  4. No RTTI.
  5. No dynamic memory allocation, new/delete must not be used, placement new is allowed.
  6. No IO, including indirect dependencies, e.g. force the demangler not to use any IO.
  7. No locale support (mostly used by IO).
  8. No floating point support.
  9. No other big features like file system.
  10. Options to simplify porting threading to RTOS.
  11. Options to simplify porting clocks to RTOS.
  12. Options to simplify porting to different C libraries.

Other topics:

  1. Code size vs performance hand-optimized implementations.

    • Algorithms may be a good example here.

  2. Multiple small switches vs one embedded configuration that configures everything at once.

    • Individual options seem to be more practical since they allow creating custom configurations.

Discussion

  • Fuchsia already uses multiple versions of libc++ with tweaks like above.

  • Actions? All: Try to implement and upstream such configuration options as people work on toolchains with specific libc++ configurations.

  • Pre-submit builders to check that the options still work are needed. Is this a prerequisite by maintainers anyway?

Follow up on previous topics

Multilib support status

  • The plugin prototype presented by Mikhail was finished, so we know the info needed to make the whole approach work. Next question is what is the best way to define this info.

  • Still need to evaluate DSL options to capture the same info.

  • One of ideas is to have build attributes with partial order defined on them, so that the multilib logic can search and pick the best match. Fuchsia uses a similar idea of “priority” to pick up the best variant.

  • DSL options: