LLVM Embedded Toolchains Working Group sync up

2024-10-10

Participants

  1. henry

  2. Todd Snider

  3. Scott

  4. Vince Del Vecchio

  5. Petr Hosek

  6. Jonathon Penix

  7. Garvit Gupta

  8. Daniel Thornburgh

  9. Alexey Karyakin

  10. stan

  11. Anton R.

  12. Ana Pazos

  13. Simon Cook

  14. Ken Matsui

  15. Prabhu

  16. Paul Kirth

  17. Panka

  18. Sam Elliott

  19. Pankaj Gode

  20. Tue Ly

  21. Anmol P. Paralkar

  22. Peter Smith

  23. Volodymyr Turanskyy

Agenda

  1. Code reviews:

  2. Community:

Discussion

Reviews

  • Peter: Custom multilib flags - reviews are welcome.

    • One point from the RFC discussion lats time was using -print-multilb-flags option output for builds systems (like GCC) to build actual library variants.

      • The key question is how to express difference between library variants (that are not represented on the command line, e.g. multithreaded vs not)

      • One way could be to add -D based on the custom flag, however these can clash easily with user defined options, and more importantly libraries could already have their own macros defined in a way that does not follow custom flag names (thus such macros would need to be mapped from custom flags names to internal library names).

      • No obviously good solution yet.

  • Daniel: LLD refactoring to provide AST: intern time is over, will need to review existing patches and follow up. Current patches can be considered as a prototype to facilitate discussions around what is possible, more than code to contribute directly upstream.

  • Garvit: Two RISC-V bare-metal toolchain objects unifying RFC comments? Petr: will be able to look after the dev meeting.

Dev Meeting Workshop

  • Peter: Where to keep records about Dev Meeting/Workshops discussion and decisions? RFCs easily tend to move down off screen and are difficult to find. Can we use Github issues with correct labels? Previously it was agreed in this workgroup sync to add the “embedded” label to LLD issues.

  • Petr: Call for demo presentations: so far there are 4-5 suggestions only, ~10 min allocated to each. More are welcome.

    • Request to Peter to have a presentation about LLD and GNU LD differences.
  • Petr: High level time allocation:

    • Start at 8 am: demos for 2 hrs.

    • A break.

    • Continue with discussion at ~10:30 am till 12 pm.

Startup code

  • Peter: The biggest issue for porting from our experience is startup code for embedded systems.

    • The default startup code is good for testing and simple applications, however it is monolithic and as soon as someone needs to do any special HW initialization, they have to rewrite the whole startup code - we will be looking into ways to modularise and give opportunity to override/extend the startup sequence.

    • Any best practices to share between toolchains in this area? Debug techniques for the same?

  • Nick: It was discussed with picolibc maintainer, if the startup for code can be reused for LLVM libc. It is possible with honouring the license.

  • Petr: We also noticed that QEMU emulation is not very precise, not architectural, thus misses issues that would pop up in real HW. We are looking to make use of free Arm models for testing.

    • Can we use QEMU user mode for running tests? Christophe Lyon from Linaro team does this for GNU. There is no user mode M-profile, thus the code can be run, but with more capabilities, thus some real HW limitations may be missed in testing.

    • Tue was able to use QEMU user mode and the performance is significantly better.

JSON linker maps

  • Petr: JSON link maps: discussed, but were not implemented. What is the status?

    • Ana: Will pass the question to the linker team, they will be in the Dev Meeting to discuss in person. Overall, work in progress, but the roadmap is TBD.

    • Could be a good intern project for next summer, so it would be nice to align expectations to avoid wasted effort.

Announcements

  • Volodymyr: LLVM ET 19.1.1 binaries were published.

    • Adds LLVM libc package for users to try and our team to continue evaluation and try to fill gaps for particular workloads requested by our stakeholders.

    • Adding FVP (Arm Fixed Virtual Platforms) support is coming for testing. These are free to use, so can be used for independent testing by others. QEMU testing will remain where QEMU provides support.