2024-03-28 LLD map-file improvements
Participants
-
Henry Cox
-
Parth
-
Nick
-
Michael Jones
-
Scott
-
Anton Rapetov
-
Nathan Sidwell
-
Todd Snider
-
Anmol Paralkar
-
Garrett Van Mourik
-
Tue Ly
-
Krushna Parmar
-
Volodymyr Turanskyy
Agenda
- [RFC] Improve map-files for effective analysis and debugging 1
- Any code reviews to highlight.
- Any updates on the previous topics: code coverage, LTO, ROM patching.
- Community events highlights:
- FOSDEM 2024 - LLVM devroom recordings from Feb
- 2024 European LLVM Developers’ Meeting details, Apr 9-11
- Embedded Open Source Summit | LF Events details, Apr 16-18
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)
-
The team tries to define what are the minimal runtime requirements, e.g. how printf should behave on different targets.
-
There are some LLVM defects about lifetime markers that result in excessive stack usage, which is rather bad in embedded systems. Help is welcome if anyone is available. Issue links:
ROM patching (Ram)
- RFC in progress, expect to be published in a few weeks time.