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