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

James Henderson via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 30 03:42:37 PDT 2019

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
llvm-objcopy isn't ready for Mach-O, but does have ELF and limited COFF
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
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
Jake: Searched 10 big projects for initial llvm-objcopy functionality.
James: File bugs to help populate GSOC backlog.
srec support possible for GSOC candidates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190430/bfde42d7/attachment.html>

More information about the llvm-dev mailing list