LLVM Embedded Toolchains Working Group sync up

Community
70

2024-09-12

Participants

  1. Alan Phipps

  2. Alexey Karyakin

  3. Ana Pazos

  4. Colin McEwan

  5. Daniel Thornburgh

  6. Garrett Van Mourik

  7. Henry

  8. Hongyu Chen

  9. Jonathon Penix

  10. Ken Matsui

  11. Partaror

  12. Parth

  13. Petr Hosek

  14. Prabhu

  15. Ram Nalamothu

  16. Sam Elliott

  17. Scott

  18. Shakti

  19. Stan Kvasov

  20. Todd Snider

  21. Tue Ly

  22. Vince Del Vecchio

  23. YUNG-CHIA LIN

  24. Peter Smith

  25. Volodymyr Turanskyy

Agenda

  1. Code reviews and RFCs:
  1. libc++ support with libc status/progress/help needed.
  2. Community: US Dev Meeting workshop preparation 2024 LLVM Developers’ Meeting - Registration & Workshop Announcement 1

Discussion

Reviews

  • Custom flags for multilibs: RFC to discuss and implementation patch in progress.

  • Petr: mixed feelings:

    • Supportive that we need a solution here,

    • Question: not the best spelling of the command line option, but no better alternatives to suggest.

      • “flag” may be confusing as a term, maybe we could try something completely different like a “feature”, but flag is already used in the yaml file, so maybe consistency is better, than a new term.

      • Namespacing idea sounds interesting.

      • Do we need additional options that are required with a particular version of the library to be specified? Need specific examples to consider the impact.

      • Alternatives like GCC spec files or clang config files and templates we want to avoid.

  • Sam:

    • How this interacts with multilibs printing with location and corresponding build flags?

    • There are use cases when multilib printing is used in the reverse direction: to asl the compiler which library variants to build. How to make it work with yaml? Sam will add a comment in the RFC.

  • Option to define an error in multilib yaml

    • Petr: FatalError name sounds a bit strong, maybe we want to add both errors and warnings => follow up change, YES. Volodymyr will follow up.

LLD lexing/parsing improvements

  • Hongyu: WIP, feedback is welcome. MaskRay is on holidays now, will need a review when available.

libc++ with libc status

  • Now libc++ is used with Raspberry Pi Pico SDK GitHub - raspberrypi/pico-sdk, a lot of limitations and workarounds though.

  • Added CMake option in libc++ to select the C library to use LIBCXX_LIBC similar to selecting the ABI library, etc. Just two values now for system and libc.

  • Summary of remaining issues to address:

    • Similar CMake option is needed in ABI library.

    • In libc++ there are ifdefs for platforms and such, suggestion to add more configs and make use of it, hopefully replace existing ifdefs.

    • Even when all possible libc++ configurable features are disabled, there are still missing pieces: get_time POSIX function, now replacement timespec_get function patch is in progress.

    • Error logging in libc++ uses fprintf(stderr, …) which is missing in libc, suggestion to refactor libc++ to avoid using fprintf() directly. Same in ABI and unwind libs. Discussed in recent libc++ sync and agreed that it is a good idea to refactor.

    • Afterwards next steps would be to add support for optional features that libc++ expects from libc. E.g. API for vendors to implement threading in a way that it can be plugged into libc and/or libc++

    • Wide char may be one topic, also disabling wide char in libc++ disables a lot of other useful features like streams.

  • Maybe best to discuss the implementation plan in the Dev Meeting and setup a breakdown of issues that we can work on in parallel.

  • TI: threading - what can be done for RTOSes to implement libc++ threading API? Would be interesting to define the problem to solve as a design constraint for the API design.

Any details would be interesting to share.

  • One idea is to retarget libc++ onto the C11 C lib API. May be not efficient, e.g. C11 recursive mutex is a flag, but in C++ recursive and non-recursive mutexes are different. So in many cases it is difficult to map.

Dev Meeting preparation

  • The announcement was posted with details, see 2024 LLVM Developers’ Meeting Embedded Toolchains Workshop

  • Plan for the workshop is to divide into sections:

    • Intro round: who is who and who is working on what.

    • A few short presentations: show-and-tell style, demos - reach out to Petr or Peter to suggest topics.

    • A set of topics to deep dive, take more formal notes and post them on Discourse to follow up.

AoB

  • Docs for Fuchsia build with CMake cache files: expected to be a presentation in the Dev Meeting.