<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 6, 2020 at 9:15 AM James Henderson <<a href="mailto:jh7370.2008@my.bristol.ac.uk">jh7370.2008@my.bristol.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 6 Feb 2020 at 00:24, Jon Chesterfield via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>This doesn't sound right. GNU binutils have a large quantity of legacy cruft, not least the redundancy between tools like readelf and objdump which are capable of doing the same task in exchange for different command line arguments.</div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Our from-scratch binutils suite has the opportunity to be much easier to use than GNU's tooling. Where was this policy, which sounds like replicating their design mistakes bug-for-bug, agreed upon and documented?</div></div></div></blockquote><div>
<div>Many tools (readelf, objdump, nm, objcopy etc) are used in many people's build systems... principle is discussed on multiple reviews of changes for the tools too.</div></div></div></div></blockquote><div><br></div><div>Thanks for your response. I read through the links but haven't gone looking for diff reviews.</div><div><br></div><div>Yes, I see why people presently using gnu tools would want llvm tools with corresponding names to behave identically. My concern is that meeting this goal takes time from the very few binutils developers that could otherwise be spent producing new binary manipulation tooling. Programmers wanting to rewrite their binaries doesn't necessarily imply a determination to stick with the GNU API - your example of generating json instead semi-arbitrarily delimited text is a good example.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div></div><div>To be clear, if there is a bug in the GNU tool, we don't try to match that. We've also made multiple extensions and improvements over what GNU does in some tools, some of which were also adopted in the GNU equivalent afterwards.</div></div></div></div></blockquote><div><br></div><div>Bugs vs features are a bit context dependent but I'm glad to hear dev effort is also going on improving matters. I'm not in the binutils space (as a dev or as a user) anymore so haven't been paying much attention to it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Note that there are some tools (llvm-readobj, llvm-symbolizer) which are not GNU compatible, and go their own way in output styles and command-line processing. These both have switches and tool aliases that allow them to be used in a GNU-like manner though too.<br></div></div></div></blockquote><div><br></div><div>Taking it on faith that the llvm binutils are implemented as a relatively thin layer on top of libraries, perhaps we should ship 'objdump' which takes the same arguments as gnu objdump and does our best effort at matching the semantics, and also ship llvm-objdump which is under no obligation to match arguments or the precise semantics. Optionally as the same file which checks the name it was invoked as. That would avoid a proliferation of strip-all-gnu and similar.<br></div><div><br></div><div>Thanks,</div><div><br></div><div>Jon</div></div></div>