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?