LLVM Embedded Toolchains Working Group sync up

Community
62

2024-04-25

Participants

  1. Parth

  2. Alexey Karyakin

  3. Ana Pazos

  4. Anmol Paralkar

  5. Anton R.

  6. Daniel Thornburgh

  7. Garrett Van Mourik

  8. Garvit Gupta

  9. Jonathon Penix

  10. Paul Kirth

  11. Peter Smith

  12. Petr Hosek

  13. Prabhu

  14. Ram Nalamothu

  15. Scott

  16. Stan Kvasov

  17. Vince Del Vecchio

  18. Wyatt

  19. Todd Snider

  20. Volodymyr Turanskyy

Agenda

  1. Follow up on [RFC] Improve map-files for effective analysis and debugging - #16 by partaror_07 1 discussion.

  2. Follow up on [RFC] A user-guided ROM patching mechanism for embedded applications discussion.

  3. (Petr) Feedback on RFC: Support for Memory Regions in ELF

  4. (Petr) Feedback on [RFC] LLD --enable-non-contiguous-regions

  5. (Todd) Assistance for debugging embedded applications built with LTO?

  6. Not discussed, FYI-only: Interesting discussions in the community:

Discussion

LLD map-files improvements RFC (Parth)

  • Refresh from last time.

  • Petr:

    • There is an old Phabricator review ⚙ D63190 Add -gnu-map option to emit a map file in the GNU-tsyle format. for an GNU LD compatible map file implementation. There are a lot of projects that consume LLD map files, so we should preserve the current format for compatibility.

    • Having a JSON format we would be able to process it easier as well as transform it into different specific formats.

    • Proposal is to use JSON + a transform to existing LLD format for compatibility. Make the default output as GNU LD.

    • JSON support is how other tools approach the issue, it would be good for consistency of LLVM binutils user experience.

  • A possible con against JSON: JSON grows very quickly because of a lot of duplication of information, so for big projects it can easily become unmanageable. A workaround could be to make the output a compressed stream.

  • Peter: Configurable level of detail of the resulting map file - we have the same in armlink as --info command line option, works nicely.

  • Peter: What to include in the output? What is provided in the GNU LD file sounds good already.

    • Possible additional information to provide:

      • Expressions for debugging

        • (Petr) now there is no good way to extract something like AST from LLD, there is an effort to re-do the LLD parser to create a proper AST, then build IR and have a pass manager with clear passes. This would enable expression debugging additional info. Equally, we can use print-before/print-after for a pass like in clang, for debugging, which might be better than dumping it into the map file. This will be worked on over the summer as a project.

        • (Peter) There may be an opportunity to progressively print out values as expressions are evaluated, but this is likely to be not very user friendly.

        • (Daniel) Current lambda function based LLD implementation of parsing and processing linker script files may not be optimal either, so will benefit from the rework into AST/IR.

      • Tool version and the actual command line:

        • Agreed. Analog of “-grecord-gcc-switches” command line option would be very useful.

ROM patching

  • Peter is reviewing and will comment, hopefully, next week.

  • The main concern is, if the added complexity justifies the use case.

Memory Regions in ELF

  • Peter commented.

  • The key issue is that attribute(section) now can be merged by the compiler.

  • Proposal to create a mapping to memory regions and allow selection specific ones.

Enable non contiguous regions in LLD (Daniel)

  • There is the RFC and a patch for automatic placement to distribute across regions.

  • Peter: Is it possible to get “cycles” that never converge? → no, there is a mechanism to ensure progress or link failure.

  • Scott: RFC: Support for Memory Regions in ELF This is something I have worked on in the past to address section placement overflow particularly when working with non-contiguous memory regions e.g. ARM’s SRAM_L and SRAM_U - Prior Art Database - IP.com.

Debugging LTO (Todd)

  • (Peter) there may be multiple dimensions to the problem:

    • Debug info?

    • Difference in behaviour?

    • Code removed?

  • Peter: General recommendation may be to “bisec” split LTO non-LTO pieces of build and gradually move into the LTO scope.

  • Other experience:

    • Scott

      • Debug info usually is OK

      • There is the memory region problem - cannot palace where needed.

    • Paul

      • Usually the code has a lot of bad assumptions about inlining, changes across TUs.

      • How to debug: save-temps/IR between passes - similar to debugging a compiler. GCC is a bit easier to use because of the different LTO model.

      • Optimisation marks can also be used, e.g. for tracking of inlining.

  • Todd: Can we provide before/after views to simplify debugging to show the user what happened?

63

Just a little more detail about my LTO debug comment …

By “before/after views” I am referring to a function’s references as determined by the linker both “before” and “after” the LTO recompile is invoked from the linker. Perhaps the linker could write the before and after reference graphs to an XML file that could be fed into a script and yield a human readable representation?

I am imagining a user in a debug session trying to figure out how the debugger’s display of their source code corresponds to the disassembly display.

If they can see a function’s “before” and “after” references side-by-side, they may get a better idea of what the LTO recompile did to their function.

~ Todd

1 Like
64

Sorry for the late notice, is there an extra spot today for ROM patching discussion?

65

Sure, added to the agenda.

66

2024-05-23

Participants

  1. Alexey Karyakin

  2. Ana Pazos

  3. Anton R.

  4. Daniel Thornburgh

  5. Eli

  6. Fangrui Song

  7. Garrett Van Mourik

  8. Hongyu Chen

  9. Jonathon Penix

  10. Michael Jones

  11. Nick Desaulniers

  12. Paul Kirth

  13. Peter Smith

  14. Petr Hosek

  15. Prabhu Rajasekaran

  16. Scott

  17. Shakti

  18. Shankar Easwaran

  19. Simon Cook

  20. Stan Kvasov

  21. Todd Snider

  22. Vince Del Vecchio’s iPhone

  23. Volodymyr Turanskyy

  24. YUNG-CHIA LIN

  25. Yvan Roux

  26. Zhi Zhuang

Agenda

  1. Any code reviews in progress.
  2. ROM patching discussion.
  3. US LLVM DevMeeting workshops.
  4. Progress update by Petr.
  5. Upstreaming llvm-elf2bin, see New tool ‘llvm-elf2bin’. (NOT READY FOR REVIEW – NO TESTS) by statham-arm · Pull Request #73625 · llvm/llvm-project · GitHub , any interest/next steps?
  6. Interesting discussions in the community from last time:
  1. Community/conferences:

Discussion

Reviews

ROM patching (Ana, Alexey)

  • (Slides presented)

  • Why: Reduce use of RAM by using more ROM for code.

  • What: Mechanism that is standard and easy to use - there are a lot of different solutions now, some of them only work for C, not C++.

  • Q:Can HW patching be used for this? A: It is orthogonal to the SW solution.

  • Options:

    • IFUNC - indirect functions, con: requires runtime resolution, works only for code.

      • Can it be done as a post link step, not on startup? Yes.

      • Not suitable for data - will need to wrap into a getter/setter function as a workaround.

      • Some targets do not support IFUNC.

    • Weak symbols - not exact match for the need.

      • Fangrui: Weak symbol | MaskRay if you use weak definitions, there would not be unresolved symbols (zero). I just had a bug that was due to weak symbols. I’d suggest against using it.

    • -fPIC, -fsemantic-interposition

      • Q: May not need PIC strictly.

    • Symbol visibility

    • -fpatchable-function-entry, xray

  • Proposal:

    • Marking step: reuse IFUNC attribute.

    • Precompute the pointers at link time.

    • Patch ROM code based on --just-symbols

  • Qs:

    • LLVM IR changes? No, not needed.

    • How to disable optimization? Can use -fsemantic-interposition

    • Previous Arm implementation was difficult to maintain because of new features coming in and breaking ROM patching assumptions. May benefit from clear bounds of support/compatibility and overall maintenance strategy/policy in regard to features that are incompatible with ROM patching.

    • May not work well for C++ still, especially with templates, also COMDAT sections in general.

      • Fangrui: C++ member function patching can use pointers to member functions. The syntax is not exactly like member function, but probably makes the intention clearer.

    • May not work well with thinLTO.

    • Any open-source projects that use IFUNC? A: glibc, xz (older version), some string functions in Bionic, FreeBSD kernel. Function multiversioning uses IFUNC as well, but it targets hosted environments. IFUNC is useful where the same code needs to run on different HW with possible different capabilities - usually not the case for embedded code.

US DevMeeting (Petr)

  • Last year workshop was a success, link LLVM Dev Meeting 2023 Embedded Toolchains Workshop Notes Happened the day before the meeting itself.

  • Is there interest to setup one this year? Who is interested to join and/or help organize.

  • Peter: depending on travel arrangements, but can help with org anyway.

  • Nick: makes a lot of sense - just go ahead.

  • Happens mid Oct, same place, see 2024 US LLVM Developers' Meeting - October 22-24!

  • Idea: adding time to demo useful features that proprietary toolchains provide.

  • Petr will submit the proposal.

Progress updates (Petr)

AOB

  • Michael: There is a plan to rename the quick_exist function in LLVM libc baremetal targets, heads up for possible breaking change.

  • Volodymyr: Having the KASan samples, is there still scope for ASan porting to bare-metal?

    • Yes, KASan is very much tailored to Linux kernel, regular ASAN is better fit in general, e.g. Fuchsia ended up switching from KASan to ASAN.
1 Like
67

2024-06-20

Participants

  1. Petr Hosek

  2. rouxy

  3. Nathan Sidwell

  4. henry

  5. Volodymyr Turanskyy

  6. Daniel Thornburgh

  7. Ana Pazos

  8. Prabhu

  9. Shankar Easwaran

  10. Anton R.

  11. Alexey Karyakin

  12. YUNG-CHIA LIN

  13. Garrett Van Mourik

  14. Vince Del Vecchio

  15. Parth

  16. Sam Elliott

  17. Jonathon Penix

  18. Ram Nalamothu

  19. Garvit Gupta

  20. Parth

  21. Peter Smith

  22. Parth

Agenda

  1. Any code reviews in progress.

  2. Follow up on the discussions from last time.

  3. (Petr) Layout in linker script accounting data locality (hot code and hot data together).

  4. Community:

Discussion

Code and data locality in linker scripts (Petr)

  • Petr: What could be a way to achieve this without much manual placement?

  • Peter: In armlink: sections that need specific placement need to be identified manually, the rest of sections are automatically allocated. There were not a lot of complaints, so no much improvement/automation.

    • Sections need to be annotated so that linker can filter them, otherwise maybe driven by profiling?

    • Peter: There is a profile driven section layout within one section.

    • Peter: armlink has a feature to avoid veneers, i.e. cross section calls, so tries to put functions closer together.

    • Petr: Trying to make use of profile data to drive linker.

    • henry: Is there a doc/spec? We are doing maybe something similar - need more information about the use case to judge.

    • Daniel: requirements/use case: no-MMU, no-cache HW first. Extend section packing, if possible.

Reviews

US Dev Meeting Workshop (Petr)

LLVM libc news

  • Fuchsia team added bare-metal allocator in LLVM libc, plan to eventually improve similar to pigweed features.

  • Support for printf in bare-metal configuration - expect vendor to implement a hook to handle chars.

  • Looks like there is a growing API for a vendor to implement to port LLVM libc to a specific use case. We need to try to better define and guide how this API evolves. Could be a topic for the workshop.

    • newlib has libgloss, alternative is to have subsystems that can be individually replaced.

    • Peter: for threading we had to do two builds to avoid calling empty functions in non-threaded configuration, to avoid the code size and performance overhead.

68

2024-07-18

Participants

  1. Alexey Karyakin

  2. Ana Pazos

  3. Anton R.

  4. Daniel Thornburgh

  5. Ed

  6. Ed Jones

  7. Eleanor Bonnici

  8. Garrett Van Mourik

  9. henry

  10. Jonathon Penix

  11. Paul Kirth

  12. Peter Smith

  13. Petr Hosek

  14. Prabhu

  15. Sam Elliott

  16. Scott

  17. Shakti

  18. Shankar Easwaran

  19. Simon Cook

  20. stan

  21. Vince Del Vecchio

  22. Vince Del Vecchio’s iPhone

  23. YUNG-CHIA LIN

  24. Volodymyr Turanskyy

Agenda

  1. Code reviews to highlight.

  2. Plan for LLVM libc package in LLVM Embedded Toolchain for Arm.

  3. Follow up on the discussions from last time.

  4. Community:

  5. AOB

Discussion

Code reviews

None to highlight.

LLVM libc in LLVM Embedded Toolchain for Arm (LLVM ET)

  • Volodymyr: We are working on creating an overlay package of LLVM libc similar to newlib one (LLVM-embedded-toolchain-for-Arm/docs/newlib.md at main ¡ ARM-software/LLVM-embedded-toolchain-for-Arm ¡ GitHub) - target for LLVM 19 based release in October.

  • We are using LLVM ET and Arm Development Studio examples for initial testing.

  • Petr: Raspberry Pi Pico SDK porting to use LLVM libc is progressing and close to be finished.

  • Petr: LLVM libc++ integration with LLVM libc - only started now. A workaround landed recently, the main issue now is logging/messages using fprintf to stderr in libc++. There is a design proposal how to handle this in libc++. Aim is to build a very minimalist configuration of libc++ without threading, wide charts, etc.

LLVM US Dev Meeting workshop

  • No confirmation yet.

  • Most interesting topics to address so far:

    • Embedded interface/API layer in libc and libc++.

    • Linker improvements, LTO.

LLD parsing improvement

  • Petr: Summer intern started improving LLD parser.

    • Diagnostic is not a focus specifically, more general improvement including performance and internal representation. Also adding unit tests.

    • With the new AST it should be easier to work on LTO improvements.

    • Having lexer/parser as a library would allow making tools on top of them, e.g. a formatter for linker scripts.

    • Even defining a formal grammar (like GNU LD has) would be useful.

    • Makes sense to create an RFC in Discourse.

  • Vince: Another use case could be post-link optimization using Bolt for embedded systems. Need a way to ensure user requirements for placement are honoured. Does anyone else doing something like this?

    • Closest could be LTO.

    • Bolt assumes one big TEXT section, this needs to be worked around for embedded.

    • If a binary was not stripped, then some information may be available.

    • May be useful to have a separate file with the meta information that can be read after linking.

    • Bolt is allowed to change placement, but within the original constraints.

    • Could Bolt have an option to output a relocatable image?

    • Could we bring some of the features of Bolt back into the linker? Or make Bolt an option pass in LLD?

    • A hope is that Bolt can help avoid a lot of cache noise. Cache model is now in the Bolt itself. It looks like frequently users encode cache related information in linker scripts implicitly.

    • Bolt only supports 64-bit now, though some 32-bit support is coming.

Embedded malloc in LLVM libc

  • Daniel: libc malloc was added recently. Aimed to be comparable with what newlib and other embedded libraries support.

  • The trade-off seems to be space efficiency vs real-time guarantees.

  • Peter: Arm libc approach: size for default case is more important. For real-time requirement it is actually very strict real-time requirements from regulation, CppCon talk about automotive memory allocation in C++ (did a plugin to find out all allocations and make a system to pre-allocate). So the expectation is to make it small and as fast as possible.

  • dlmalloc has a lot of code to optimize for time efficiency.

  • Scott: two level segregated algorithm (TLSF) is a good option. It is fast since it is based on predefined block sizes, faster than dlmalloc.

69

2024-08-15

Agenda

  1. Pico2 launch
  2. Embedded toolchains workshop
  3. Code reviews and announcements

Pico2 launch

The SDK for Raspberry PI pico 2 supports clang and llvm-libc. The SDK fully works with llvm-libc including tests.

Some workarounds needed for llvm libc++, hopefully will go away in the next few days.

https://www.raspberrypi.com/news/google-pigweed-comes-to-our-new-rp2350/

Embedded toolchains workshop

Workship now approved, happening a day before the LLVM dev meeting on the 22nd October. Will be A morning slot 9 - 12:30 with Lunch included.

  • Program will be developed over over the coming Months
  • A couple of deep dives rather than trying to replicate the conference.
  • Would like to do an introductory session as there were a lot of people attending last time. Where are people coming from, what are their concerns, what would they like to see, what are they working on?

Code reviews and announcements

No outstanding reviews requiring attention.

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.
71

FYI: I’ve submitted a proposal for an embedded systems round table at the dev meeting. Using the same agenda as 2023 Session Details: 2023 LLVM Developers' Meeting

72

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.

73

2024-11-07

Participants

  1. Alexey Karyakin

  2. Ana Pazos

  3. Anmol Paralkar

  4. Anton Rapetov

  5. Garrett Van Mourik

  6. henry

  7. Jonathon Penix

  8. Ken Matsui

  9. Paul Kirth

  10. Peter Smith

  11. Petr Hosek

  12. Sam Elliott

  13. Stan Kvasov

  14. Ties Stuij

  15. Tue Ly

  16. Vince Del Vecchio

  17. Volodymyr Turanskyy

  18. YUNG-CHIA LIN

Agenda

  1. Code reviews:

  2. LLVM libc printf code size optimization.

  3. Default for frame pointer for Arm bare-metal.

  4. Community: LLVM DevMeeting follow ups:

Discussion

Code reviews

  • Multilib custom flags

    • Sam: Extra build args make sense. Need to clarify if these are cc1 args or ones for the driver itself?

      • Petr: Slightly prefer driver args, as they are more user friendly (not internal details that people may not be familiar with).

      • Peter: Agreed, we also wanted more stability, thus depend on public args. No restrictions or strong opinion though.

    • Petr: Overall no big concerns over the RFC, next step - review the implementation.

Petr: LLVM libc printf code size opt

  • Petr presented slides by Daniel to summarize the 3 options being considered.

  • (1) A special function like “iprintf” is in clang and does not use FP, available for emscripten and xcore targets.

    • Could be “_small_printf” or similar name to highlight that it is non-standard.

    • => benefit - already is in clang; there is a prototype implementation.

    • Ana: We tried to upstream the same into Musl C library, but it was rejected because it is not a standard C API. LLVM libc team considers that it is OK to have extensions in LLVM libc. May use a different name to avoid confusion, can use underscores to highlight not standard

  • (2) Weak implementations of multiple functions per format specifier to print or such; compiler will generate a strong reference only to used sub-functions, the rest would be garbage collected to save size.

    • Peter: This approach was used in Arm Lib C.

    • => compiler implementation will be a bit more complicated, than the 1st option.

  • (3) Call site splitting - most involved implementation - replace (rewrite) printf with multiple calls to simpler functions in place.

    • Peter: code size can grow, because of expansion in place, so depends on actual usage in an app.

    • Petr: idea: try to do it as constexpr implementation in C++?

    • Vince: what is the expected advantage of this? If there are only few simple/constant args, then can save on parsing the format string and replace with only basic function calls

  • RFC about these options would be great, Arm team can also add details of our current implementation in Arm Lib C to the RFC.

Peter: frame pointers on or off by default?

Dev Meeting follow up

  • Workshop went well, very good participation.

  • Petr: setup a feedback form, feedback so far: people would appreciate having a full day workshop. Deep dives were great, wanted more. Petr will take to organizers. May skip talks next time as well to give more time for discussions.

  • Petr: ELF TLS in LLVM libc - tried to avoid TLS implementation so far, can make configurable (a function call vs TLS).

    • There are other more critical things now, e.g. semihosting.

    • Peter: TLS is useful if there is a lot of usage of thread local variables, otherwise the impact is small.

  • Peter: PIC in embedded discussion was insightful.

    • In most cases, not used, but if it is needed, then there is no workaround.

    • clang can do PIC, ROPI, RWPI today, but they do not work for C++ really.

74

2024-12-05

Participants

  1. Ana Pazos

  2. Daniel Thornburgh

  3. Garrett Van Mourik

  4. Garvit Gupta

  5. henry

  6. Hongyu Chen

  7. Ken Matsui

  8. Pankaj Gode

  9. Paul Kirth

  10. Petr Hosek

  11. Prabhu Rajasekaran

  12. Sam Elliott

  13. Scott

  14. Soumi Manna

  15. stan

  16. Ties Stuij

  17. Todd Snider

  18. Tue Ly

  19. Vince Del Vecchio

  20. Volodymyr Turanskyy

  21. YUNG-CHIA LIN

  22. Peter Smith

  23. Victor Campos

  24. Michael Jones

Agenda

  1. Reviews/discussions:

  2. Follow up on previous topics.

  3. Admin topics

  • The call on 2nd of Jan will be cancelled, so the next sync will be on 30th of Jan 2025.
  • Volodymyr will update the dial-in link to use Google Meet.

Discussion

Reviews

Victor: Mutilib custom flags

  • Restrict arguments to macro definitions only? No known use cases otherwise today, however would it be too restrictive?

    • Petr: Arbitrary flags sound too permissive and can create too powerful/confusing solutions. So starting with a more restricted approach and expanding in the future may be safer.

    • Sam: Supports restricting now and extending as needed in the future.

    • Peter: It is easier to add, than to remove features in the future, so also supportive.

    • Victor: Agreed that it will also simplify the implementation

    • => Victor will update implementation to support macros only.

Ties: Frame pointer off by default for Arm

  • Comments addressed, ready for final review.

  • => Petr will confirm.

Michael: printf code size optimization

  • Was discussed in last libc sync: Monthly LLVM libc meeting - #29 by michaelrj-google

  • Michael: No hard decisions yet, however it seems like people are willing to make more sacrifices for code size, so they want more options to tweak.

    • Would be good to get more data/overview of what options are used and how much size this can save?

    • Peter: FP is the biggest (>50%?), removing additional formatting options like “%04d” helps a lot too.

  • Daniel: Idea: Abstract interpretation and LTO to find exactly what paths are hit?

    • Can cause quite some maintenance burden to structure code in a special way to be able to add/remove small pieces of logic.

    • May start slowly (FP, fixed math, etc) with options that give very big savings, then consider smaller saving cases.

    • Peter: Makes sense as long as it is done in a backwards compatible way so that we can improve in the future.

  • => Peter will try to get/summarise usage data.

  • => Daniel to see how to split up the big known pieces of code like FP.

Daniel: malloc review

Garvit: Merging toolchains

Petr: libc for libc++ status

Key issues in progress:

  • libc++ detecting if the new operator is overridden works by putting it into a special section: prevents garbage collection if there are unused implementations (optimization issue), but also most linker scripts do not account for this special section (correctness issue). Working with C++ team now, the first attempt was to add an option to disable this at all, but now reviewing other options. Aliases are considered now: there is an implementation, but there are some implementation details to resolve for machO. https://github.com/llvm/llvm-project/pull/114961

  • filesystem used gettime POSIX API, should be replaced with timespec_get C11 equivalent that was added into libc, there is an existing PR for libc++ to make use of. [libcxx] Support for using timespec_get by petrhosek ¡ Pull Request #117362 ¡ llvm/llvm-project ¡ GitHub

  • print header unconditionally uses FILE*, but it not in libc at all, may be added for semihosting later (but still under an option). libc++ team supports option to disable FILE* use and direct to stdout. PR expected soon.

  • libc++ works libc, but no libc++abi/libunwind building support yet, needs CMake changes.

  • Hope to solve these immediate issues and start working on improvements next year.

  • There will be more opportunities to help with optimisations in the future.

Daniel: LLD refactoring

  • The patches still need to be properly reviewed.

  • Petr: Will need a lot of code reviews for all the refactorings, Fangrui Song (MaskRay) is now less available for reviews so community help will be needed.

  • Peter happy to help, should make sure RFC in general are also approved with Fangrui.

  • LTO improvements depend on this refactoring, e.g. when it is needed to find strongly connected components, linker script analysis should be done, thus needs the refactoring to get linker script info easier. However the refactoring may be bigger than just needed for LTO, e.g. better error messages.

  • Peter: It is easier to review when there is an end-to-end roadmap/RFC to see where a change fits. A bigger RFC for the refactoring could be useful.

  • Petr: RFC may be useful, yes.

Peter: FOSDEM reminder

Petr: C library ABI compatibility

  • ABI compatibility with newlib: when migrating projects from Arm GCC to LLVM clang/libc there os an issue with binaries built by vendors with GCC + newlib. Some code can be difficult to rebuild with clang, thus the requirement to reuse GCC prebuil onest.

  • Builtins are mostly compatible.

  • Example issues:

    • GCC supports Thumb1 compressed switch cases (using helper builtin functions for the switch) which results in undefined refs. Should compiler_rt provide these? Is it OK to include into compiler_rt something that clang itself does not generate? This also looks like a good optimization to implement in llvm?

      • Peter: ideally, newlib should emit helpers in a comdat group as per the ABI. Otherwise would be a good thing to do, could be an option to have a helper library like newlib_compat

    • newlib has a reentrancy struct that keeps all the global state of newlib, every thread will have a copy of this struct. If errno is used in an app, then there will be a reference to this struct which is undefined in libc. errno happened to be the first field in this struct, so easy to mock, but a better solution is needed. newlib compatibility layer can be useful, because multiple projects would be hitting this. Where to put this? Maybe even a separate project under LLVM.

      • Peter: There is a 32 bit C lib ABI to define what is common about all C libs and what is implementation defined, header vs libraries, … ABI recommended to use one library and put helpers into comdat groups. Otherwise it gets very complex, e.g. the reentrancy struct can conflict with TLS implementation.

      • => Peter to provide the link abi-aa/clibabi32 at main ¡ ARM-software/abi-aa ¡ GitHub - can be used to get an overview of possible kinds of issues to expect.

      • Prabhu sometimes people will not even have code to rebuild, so some compatibility may be useful, though it is difficult. Maybe a “best effort” compatibility library that helps, but does not solve all issues.

    • This issue is somewhat similar to libc Linux overlays issues.

      • There exists llvm-libgcc which solves similar issues, so newlib compatibility library can follow the approach.

Admin

  • Next meeting on 30th Jan, 2025

  • Dial in link will be updated - Volodymyr to highlight in the announcement next time.

  • Happy holiday season!

75

2025-01-30

Agenda

  1. Code and RFC reviews.

  2. Order of libraries issue and temporary fix in LLVM ET - what should be the proper fix in upstream LLVM?

  3. Announcement: LLVM Embedded Toolchain for Arm is being moved to the new unified Arm Toolchain repository for both Arm embedded and Arm (HPC) Linux toolchains. The intention is to complete the migration by LLVM 20 based release. The structure of the toolchain is exactly the same - same build scripts in a new location.

  4. Community: EuroLLVM 2025:

  5. Updates about previous topics, AoB.

Discussion

Order of libraries

  • Is reverting the order an options? Why the change was needed? Couldreverting break llvm libc?

  • The reason for the change: All other drivers use the current order, bare-metal was an odd one, thus updated for consistency.

    • Maybe also related to merging the RISC-V and bare-metal toolchains effort.

    • Note that sanitizer and other libraries from compiler_rt are put separately at the front of the command line, so this issue is specifically about compiler_rt builtins.

  • Could the cause of the issue be in picolibc? Also newlib? Not compiler_rt or the order itself.

  • Alternative solution: Add an option to suppress inclusion of the duplicated functions into compiler_rt (they are not efficient anyway, e.g. just a wrapper around memcopy). If compiler_rt defines some functions, then it must define all of them.

    • Could be OK to remove these functions, but need to make sure it does not break anything, thus must be an option depending on the C library, not the default.

    • Could compiler_rt be used in an “overlay” mode on op of a C library? Not obvious.

    • picolibc uses symbol aliases, must be the same in newlib - is it possible to add an option not to generate the aliases?

  • => changing the order back is not the preferred option: we need to introduce an option either in compiler_rt or picolibc. Need to check which one does not define all of them.

  • In general, compiler_rt depends on libc which is not optimal. Is there room to actually improve compiler_rt?

    • It is useful to be able to call builtins from libc, i.e. libc depend on compiler_rt.

  • Wouldn’t LTO optimized memcpy be a better (more portable) solution? Is it available everywhere though?

EuroLLVM

  • Not many people are going, so a roundtable could be more appropriate, than a workshop.

Code reviews

Admin

  • Google Meet works well

    • There are two different links in the invite - Volodymyr to fix.

  • Idea: Use tags for agenda topics to make it easier to find - Volodymyr to check.

1 Like
76

2025-02-27

Agenda

  1. Code reviews: TBD, please post links below, if you have any that require attention.

  2. Topics:

  3. Community:

    • EuroLLVM 2025, for those who is going: anyone wants to meet there and discuss specific topics?

Discussion

-ffunctions-sections, -fdata-sections

  • Why it is not enabled by default in general: it increases the data section table, for big projects it can be significant. Unique name sections feature was implemented so that sections can have one name. For bare-metal, with much smaller code sizes, this might be not a concern.

  • Another point is consistency with GCC. NOTE: see https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html - the reason provided is the same: possibly bigger code size.

  • In addition it will have an impact on linker scripts: text section name patterns will need to be converted into text.* to capture all relevant sections. This could potentially be breaking for existing projects with linker scripts.

  • That said, LLD does merging of sections with suffixes and it is likely that most linker scripts already have text.* patterns anyway for other reasons.

  • => Arm team will consider an RFC or patch to facilitate the discussion.

-fhardened

  • This option sounds better on paper than in practical use.

  • libc experience: FORTIFY_SOURCE was considered, but there is a question how much to implement in the compiler vs library? Another issue is how to handle errors when the function type does not expect one?

  • In embedded systems, reporting error cases can be tricky - there is no standard way to report, print diagnostics.

  • For embedded software compiler checks (warnings) are most interesting since they do not have performance and code size impact.

  • Features which are implemented in the compiler code gen only are also OK, but once that require runtime may be tricky - runtime part in embedded can differ a lot.

  • For practical application, it is important to be able to roll out hardening gradually, thus it is easier to enable one option, e.g. a warning, at a time, instead of 10 warnings at the same time. Importing 3rd party code is also difficult as it needs to be cleaned up and may potentially need downstream patches.

  • In Fuchsia there is a lot of focus on sanitizers too, i.e. testing/debugging vs production code gen.

  • Some features can make debugging more difficult, e.g. auto var init to zero is likely to hide errors. It is better to use MSan to find the same class of defects or, at least, use auto var init to pattern, so that the pattern value is easy to spot during debugging.

EuroLLVM

  • Not many people are going, nothing to agree upfront.

AsiaLLVM

  • Is anyone going? Looks like no one from this call.

  • Call times are not convenient for people in Asia, so they are unlikely to be present in this call either.

  • Most companies have budgets for visiting one event, thus people need to decide where to go. Probably, companies that have offices in Asia are more likely to go.

77

Regarding this, I think it’s worth pointing out that the MSVC compiler makes the /O1 / /O2 flags imply /Gy, their equivalent to -ffunction-sections. So, there is solid prior art for enabling this more often outside the Linux world.

It might be too disruptive to do the exact same thing for the GCC-style clang driver, but it’s worth considering.

1 Like
78

2025-03-27

Agenda

  1. Please highlight any code reviews or RFCs that you want to discuss.

  2. Petr: Qualcomm RISC-V toolchain driver merge into the Baremetal driver.

  3. Michael: definition of -ffreestanding [Docs] Document freestanding requirements by AaronBallman ¡ Pull Request #132232 ¡ llvm/llvm-project ¡ GitHub

  4. Peter: Interest around LLVM support for Embedded Linux, e.g. Yocto, and other RTOSes.

  5. Status updates on the previous topics.

Discussion

Petr: Qualcomm RISC-V toolchain driver merge into the Baremetal driver

  • Garvit: Links:

  • RISC-V driver assumes presence of GCC installation, newlib, libstdc++, … otherwise very similar to the Baremetal driver, thus a lot of code duplication.

  • Also this will make the Baremetal driver more uniform with other drivers in the order of command line options generated for the linker.

  • Qualcomm started working on this, there are many patches, asked to breakup even further to split into independent logical changes.

  • Mostly two reviewers now (Petr and Fangrui) - anyone who has an opinion please reach out.

  • Expect changes and churn in the baremetal driver in a few weeks from now.

  • Peter: We can try to apply locally and see if anything breaks in ATfE. Arm GNU Toolchain installation can be used for testing.

  • Update from the llvm libc meeting last week (Monthly LLVM libc meeting - #36 by michaelrj-google) regarding a comment from the review: adding a command line option to select the C lib to use - people in the call have been supportive. Needs an RFC to define the details. May obsolete dependency on GCC installation in the future.

    • Observation: There are many more C libraries than C++ libraries including proprietary ones - the option may need to be open-ended, not a fixed list.

    • May need to work a bit like a config file/linker script to configure related libs, e.g. libgloss in addition to newlib.

Michael: Definition for freestanding

  • [Docs] Document freestanding requirements by AaronBallman ¡ Pull Request #132232 ¡ llvm/llvm-project ¡ GitHub

  • In the C standard freestanding implementation has a very limited list of headers, apparently people want much more from the library in freestanding (embedded) mode. Can we provide feedback to the C standard committee to extend?

  • The C standard may define the minimum implementation, but do not limit to only those headers, so implementations can add more.

  • Note: there was a big discussion about C++ re-definition of freestanding, here is a rather old roadmap P2268R0: Freestanding Roadmap, need to check if anything was accepted into recent C++ standards.

  • Peter: Rust did it in a different way by splitting the core and heap related parts.

  • Petr: freestanding is too coarse grained, just binary - projects need more levels of support

  • LLVM libc++ does not have proper support for freestanding now, instead there are multiple flags to turn on/off different features. For libc++ freestanding support effort is only about standards compliance - individual flags fit real usage better. Similarly, libc may need more switches/options to configure.

  • This does make sense to raise to the std committee - Aron may be a good contact, he joins the libc meetings.

Peter: Embedded Linux/RTOS

  • We are looking into Embedded Linux for FuSa, e.g. automotive use cases.

  • Embedded Linux app development is mostly usual Linux development, so may not be very close to embedded topics discussed in this call.

  • FuSa qualified tools require pre-qualified binaries including for libraries - cannot patch sources.

  • Yocto is one of Embedded Linux distro builders: it downloads clang source release, applies ~30 patches, builds the toolchains and uses it for the rest of build via meta-clang: GitHub - kraj/meta-clang: Clang C/C++ cross compiler and runtime for OpenEmbedded/Yocto Project, the patches are under meta-clang/recipes-devtools/clang/clang at master ¡ kraj/meta-clang ¡ GitHub

  • In order to get a binary qualified toolchain, the patches either need to be upstreamed or there should be enough ways to configure clang - Yocto is based on OpenEmbedded that uses different conventions for where libraries and other dependencies are placed, thus a lot of small workarounds.

  • Any interest in the embedded LLVM community?

  • Petr: Yes:

    • Interested in different approaches to organization of libs/runtimes/etc

    • Recently was contacted by Android Auto team to talk about FuSa in auto space. Among other things, auto team is interested in tooling provided by LLVM, e.g. static analysis, tidy, clangd, … - would these be usable for auto specific checks? Or even embedded specific checks vs POSIX?

  • Peter: We will need to think about it more and come up with an RFC.

  • Petr: What C libraries is Yocto using? maybe an interesting use case for LLVM libc to target Yocto.

    • Peter: It is configurable: glibc, musl as main could be uclibc. Can be different for FuSa where they may need to use a pre-qualified binary library.

  • Michael: FYI an existing Yocto build bot for RISC-V Buildbot

  • Peter: Qualification is expensive because of required test coverage - if upstream testing is sufficiently good, would be useful and help the community.

Petr: llvm libc update

1 Like
79

2025-04-24

Agenda

  1. Code reviews and RFC:

    • Status of baremetal driver updates discussed last time.
    • TBD: please add links in the comments.

  2. News/community updates:

    • Arm Toolchain for Embedded has got a special package that provides LLVM libc as the default library including libc++ on top of it to simplify compatibility testing. We are interested in identifying possible gaps in libc support for typical embedded projects.
    • ELD linker open-sourced.
    • UBSan applied to picolibc report by Keith Packard.
    • EuroLLVM 2025 updates, if any.

Discussion

Baremetal driver code reviews status

  • Petr: Most patches are approved by Petr and Fangrui, but there are some more recent updates.

  • Petr: suggestion: changes are stacked, so cannot land until all are approved - some of the patches could have landed already, if they were separate changes. May not be easy to split now, may be something to consider for the future.

  • Peter: multilib change: had some questions. Should not break existing things, so not blocking questions.

    • “clang-runtimes” folder and multiple places to look for libs - encourage poeple to use multilibs now.

      • Petr: agree this folder does not fit in the model of any other toolchain. There does not seem to have been a discussion when it was introduced. We may consider deprecating this layout - justifies an RFC. Maybe to start with a warning about deprecation for one release, then remove in a follow up release.

ELD linker

  • Peter: Could be a proof of concept/prototype for features we want in LLD.

  • Petr: Would not be easy to port code:

    • Based on MCLinker which is pre LLD.

    • License is BSD and NCSA - the code needs to be relicensed to be used.

  • Petr: Features that could be useful: the diagnostic engine, especially for linker scripts. Cannot move over, but can be used as an inspiration.

picolibc UBSan report

  • Petr: Experience of moving codebases from GCC/newlib to LLVM libc: there are issues with code that works with GCC, but not with LLVM - LLVM is stricter, e.g. about unaligned access. Results in either crashes or performance issues depending on HW handling of unaligned access - UBSan is good at finding these.

  • Petr: UBSan handlers from picolibc would need to be reimplemented, e.g. in LLVM libc. Would be best to implement in UBSan itself - want to avoid having the runtime in LLVM libc.

    • Peter: The minimal runtime needs to output diagnostics somewhere, in ATfE it uses semihosting, but in general may need an abstraction layer.

    • Petr: the biggest overhead is strings, so we want to keep them out, e.g. in debug sections, then have a way to either output ID of the string and expand later on the host OR traps to provide special codes to match back by the debugger.

  • Daniel: Question: generalisation of replacing strings with ID and reconstructing with symbolizer.

    • Peter: Would need the whole toolchain including the debugger from the same vendor.

    • Petr: pigweed has a tokenizer library that replaces string with a hash, then logging framework has a logic to reconstruct on the host. But this is very custom without compiler support - may be interesting to see if something like this can be supported in the compiler, but then indeed there would be a dependency between tools or need for standardisation.

    • Peter: Arm Compiler 5 used something like resource files to provide IDs for errors, then a text file with the mapping to actual error messages.

EuroLLVM

  • Apple’s keynote about memory safety was very good.

Hardened libc++ usage experience

  • Petr: did not try yet. Also interested in bounds safety feature for C.

  • Vince: the same - on the roadmap to try.

  • Petr: Note: LLVM libc always enables auto var init for all targets - came as a surprise, may need to be configurable.

80

2025-05-22

Agenda

  1. Code reviews and RFC:

    • TBD: please add your links as comments.

  2. Updates:

    • fstream support in embedded libc++ without full filesystem support discussed here: we keep getting requests from Arm Compiler users to re-enable this in ATfE. What are community thoughts?
    • –stdlib option (discussed in LLVM libc sync) next steps. We expect to have multiple libraries in ATfE later, so are interested in having a standardized way of selecting one. Current option is a config file that points the --sysroot to the folder which provides the library builds.
    • Duplicated compiler_rt/picolibc builtin symbols issue solved: LLVM PR and ATfE PR.

  3. Community:

  4. Other

    • Multilibs layout for includes: fixed vs configurable.
    • ATfE GitHub CI binaries available for Linux, Windows is coming.

Discussion

Reviews

Nothing to highlight.

fstream support without filesystem

  • Petr: We also see a need in something finer grained, e.g. serial IO instead of FILE*, would be useful to have a carve out for such a scope. Next step up could be e.g. stdin/stdout/sterr only as static files. There is a fear that it will increase complexity. Would be useful to have at least one additional carve out - may be difficult to provide a good name for it to explain what it is.

    • → bring this in next libc++ sync meeting on 10th of June.

    • → also there are some patches for review form Petr to make the discussion more concrete

  • Peter: We may also think about an interface to provide functions to link for the whole filesystem even if most of them would be stubs. The GLIBC mechanism of gnu_warning is not supported in LLD.

    • Daniel: Need to be sure that the stub is not used at run time, otherwise can be very misleading and lead to surprising run time error.

stdlib command line option

  • Petr: The main question is how cold it work exactly, e.g.:

    • Fixed hardcoded enum of known libc’s, e.g. like unwind libraries, compiler_rt vs libgcc, etc.

    • Extensible system, e.g. a yaml config file with details - fear that it can grow into GNU spec files or similar complexity.

    • Something in between: harcode most common + a fall back for the rest.

    • → Need to discuss with a proper RFC.

  • Peter: Is this a niche for embedded toolchains only? Dedicated target triples exist for muslc and glibc.

  • Michael: We observed that file organization is relatively stable, so we can have an expectation/interface defined. Can be a custom option that point to “standard” layout.

    • Petr: The issue is with non-standard aspects, e.g newlib requires libgloss to be added.

      • Peter: For some particular issues like this, linker script when a library includes for more libraries can be used.

  • → Arm team will think about an RFC

multilibs includes

  • Peter: large number of binary lib variants cause a lot of duplication of headers. The idea is to provide one headers set with multiple binaries.

  • Petr: There is supported in libc++ (e.g. Fuchsia) for include for common headers plus a target directory after the triple with __config_site file. Multiarch and multilib are supported: can have directories per multilibs. There may be no docs for this though. The driver is aware already. There are also sanitizers specific variants.

    • This approach is not supported for libc, because the headers are generated, idea: there are internal headers that are not generated, thus a similar scheme can be used with static headers.

  • Peter: For newlib and libc there is only one file that is generated and is different.

    • Idea is to extend the multilibs yaml file with additional include paths.

    • → Arm team will send an RFC.

    • Next level: layering of binary variants, e.g. optimized binaries first, then generic.

DevMeeting 2025

  • Petr will propose embedded toolchain workshop. Suggestion is to keep mostly the same format. Questions:

    • Length: half or full day? Last year attendees asked for a full day workshop - there was a lot of content.

    • Do we need a dedicated libc workshop or include it into the embedded one? Can try to ask to schedule them at different times.

    • Can be “runtimes” workshop i.e. include libc and libc++

      • → Michael to write a proposal

    • → Agreed to submit half-day embedded and half-day runtimes proposals and ask to schedule them at different, best adjacent, times.

CFI directives for inline asm

  • Petr: inline asm for interrupt handling is usually written manually and does not provide DWARF directives, thus bad debugging experience. Idea: a feature in the compiler to check CFI directives and may be even generate them later. GCC added this recently - tries to generate, but still very limited.

    • Someone is prototyping this now. RFC is coming soon.

  • Is there any prio art?

    • Peter: there was sucn a request for armasm, we tried to implement, but did not succeed, Peter to find some records of issues encountered. Mostly a lot of corner cases that cannot be resolved automatically, e.g. when the SP is changed in the code.

embedded security measures

  • Todd: What are approaches to adding checks for security against physical tempering.

  • Peter: there was experience adding NOPs that a later pass can override. Tend to be very specialized and secret, thus not upstreamable.

81

2025-06-19

Agenda

  1. Code reviews and RFC:

  2. Community:

    • Dev Meeting workshop(s) preparations.

Discussion

Includes (Simi)

  • Intent is to eliminate the copies of headers in multilibs.

  • Options: extend the multilibs yaml file or add the logic to the driver itself.

  • Adding config in the yaml keeps all logic in one place.

  • Petr: hardcoding looks almost like multiarch implementation (for which there is a convention alresdy) - will double check the multiarch support in baremetal, then respond to the RFC.

stdio implementation in LLVM libc (William)

  • Semihosting in Arm can be used to implement stdio - suggestions for the design?

  • Petr: this is in active discussion with libc team now: no concrete proposal yet, more a set of constraints.

  • This will be discussed in next libc meeting next week Monthly LLVM libc meeting

  • Will respond to the RFC main thing is: users of libc do not have to pay for what they are not using, e.g. if app only needs serial IO then it should not pull in FILE* subsystem. Even if FILE* is needed for compatibility, buffering can be on or off as an option to save space.

  • We need to define the progressive layers like for printf() with multiple levels of features and code size options. In this case, there could be room for integration with the compiler to pull in implementation based on format options - saves variants of prebuilt library variants needed.

  • William: The task at hand is to enable fprintf, std::cout

  • Petr: for the specific PR an option for stdin/stdout only can be possible without possibility to create additional files.

fstream support without filesystem (Petr)

  • As a follow up from last call, discussed in libc++ sync on 10-06-2025

  • The concern was for adding more carveouts will add a lot of complexity very quickly - more ifdefs, etc.

  • It was also noted that dependencies on file IO are all over the place, thus it is difficult to port libc++ new new platforms in general.

  • The proposal was to create a low level file system API like one exists for threading support. This API will need to be implemented for each target platform.

  • A side note, it would be great to be able to share threading API between C and C++ libraries. Same for file IO would be great too.

  • Overall suggestion was to work on enabling all of filesystem (even if parts are not supported on the target platform).

Threading in libc (William)

  • Question: How to run libc integration tests on an embedded target that does not support multithreading? There is a dependency on TLS.

  • => Bring this up in the next Monthly LLVM libc meeting

RISC-V GCC driver integration (Sam, Garvit)

  • Landed, some Fuchsia toolchain related testing issues are being worked on.

  • How to test the changes locally? There is an upstream bot. There is a CMake cache file in LLVM repo to do a local build as well. Garvit will coordinate with Petr.

Workshops in LLVM DevMeeting (Petr)

  • Waiting for the confirmation from organizers, 2 workshops requested: runtimes and embedded, asked to schedule them one after another.

RFC for CFI in assembly (Garvit)