LLVM Embedded Toolchains Working Group sync up

2024-03-28 LLD map-file improvements

Participants

  1. Henry Cox

  2. Parth

  3. Nick

  4. Michael Jones

  5. Scott

  6. Anton Rapetov

  7. Nathan Sidwell

  8. Todd Snider

  9. Anmol Paralkar

  10. Garrett Van Mourik

  11. Tue Ly

  12. Krushna Parmar

  13. Volodymyr Turanskyy

Agenda

  1. [RFC] Improve map-files for effective analysis and debugging 1
  2. Any code reviews to highlight.
  3. Any updates on the previous topics: code coverage, LTO, ROM patching.
  4. Community events highlights:

Discussion

Map-file improvements (Parth)

  • Qulcomm tools team, looking into using LLD for embedded development.

  • (Slides were presented to summarise the RFC).

  • Three main topics to discuss as follows.

  • (1) Where to put the information?

    • Options: map file, a new file, a new section in the output file.

    • Discussion:

      • Q: Does GNU LD have a description/spec for the format? A: It does not seem to be strictly defined by GNU LD.

      • Q: What is missing from LLD for people moving from GNU LD? A: E.g. input/output sections properties; expression evaluation.

      • There should be a healthy trade-off between LLD speed/memory use and maintenance vs added value of features like expression debugging. Q: How frequently is it needed? A: Sometimes.

  • (2) Map-file structure?

    • Options: Similar to GNU LD or something new/different.

    • Overall, LLVM wants to match the GNU behavior where it is well documented (to avoid changes and incompatibilities in the future). NOTE: GNU map files are not machine readable, they are mostly for debugging. There are no known tools that consume it as their input.

    • Would be useful to have command line options to choose which detailed content to add (not to generate all the information at once as the map-files are big and difficult to process already).

  • (3) Map-file format?

    • Options: Text, JSON, Yaml, Protobuf.

    • Suggestion: Maybe best to have one binary and one human readable format, rather than trying to force one format to meet both needs.

    • Usage: The team is creating map files for all builds and uses tools to analyse/visualize it.

    • Protobuf as a machine readable format has quite some benefits.

    • Suggestion: create a separate file for different type of information, start with JSON format so that it is easy to both read and parse with a script.

    • GNU LD and LLD map-files are already two different formats, so need to be parsed separately.

    • Looks like many people prefer JSON, at least, as the initially supported format.

  • Conclusion: Any decisions/suggestions need to be confirmed with MaskRay as the LLD maintainer, so action is to update the RFC and highlight to MaskRay.

LLVM libc (Nick)

ROM patching (Ram)

  • RFC in progress, expect to be published in a few weeks time.