[llvm-dev] EuroLLVM 2019 - LLVM Binutils round table notes

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[llvm-dev] EuroLLVM 2019 - LLVM Binutils round table notes

Callum Laird via llvm-dev
Hi all,

At the recent European LLVM dev meeting, there was a round table for the LLVM binutils following a BoF the previous day on the same topic. Below are the notes that I took from the round table meeting. I got names from many, but not all comments. Apologies for those I didn't catch at the time.

If anybody has anything else to add, please feel free to do so!

Thanks everybody for taking part!



Josef Eisl: binutils - usually cross-platform (can use same commands on Darwin & Linux). Not true for all tools.
Would like one LLVM tool that does the job on every platform. Should be platform independent (e.g. run on Darwin, to extract ELF, or Linux for Mach-O).
llvm-objcopy isn't ready for Mach-O, but does have ELF and limited COFF support.
Command-line compatibility is top of Iain's priorities.
We have added new flags to the LLVM tools, not available in GNU. Just need to avoid short aliases.
Symlinks for GNU compatible version of tools.
Documentation lacking from CommandGuide.
Apple are producing man pages for those tools they are using.
Maybe aim to get man pages/documentation ready for next release.
Iain: We should switch to libOption. If it doesn't fix the short-option concatenation issue, then we should add support for that.
Peter Smith: Disassembler improvements would be very useful. Especially the case for ARM.
Jake Ehrlich: PLT disassembler jmps could do with something describing the entry.
Jake Ehrlich: Symbol resolution can be an issue in disassembly.
Michael Spencer: Disassembler library needs sorting out.
James: Bugs filed would really help those who like to fix bugs.
Peter: We need some sort of priorities within the tools.
Jake: Disassembler library design should be proposed on llvm-dev.
Jordan/Michael/Iain: Output compatibility is critical for Linux distributions, particularly configure. This includes number of spaces.
Machine output mode would allow us to point people at using that instead of parsing human output.
GNU output is likely stable (if they break compatibility it is probably safe that they're not breaking anyone).
There are people who care about configure, and don't want to have to update their scripts.
Would be interesting to get an idea of how many configure scripts actually use binutils in this way.
There is a posix standard that describes general principles.
Help and version need to print to stdout and have no errors. -v output matters on Darwin.
Roland: Parsing version string matters as soon as you break command-line backwards compatibility.
Iain: Very interested in Mach-O support.
Lots of fixes recently for llvm-ar thin archives.
Cody: Is there a roadmap to show compatibility status?
No, but general feeling is that it would be helpful.
Jordan: All work for about 90% of cases.
Cody: using it for external customers.
Michael: Corpus of tests about only reliable method.
James: Searched in bugs and customer support requests to identify features needed.
Jake: Searched 10 big projects for initial llvm-objcopy functionality.
James: File bugs to help populate GSOC backlog.
srec support possible for GSOC candidates.

LLVM Developers mailing list
[hidden email]