<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi James,</div><div dir="ltr"><br></div><div dir="ltr">I also wanted to work on this discrepancy, but I just sent a patch instead of an RFC: <a href="https://reviews.llvm.org/D54124" target="_blank" class="cremed">https://reviews.llvm.org/D54124</a>. Thanks for sending the RFC that I should have started myself :)<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 6, 2018 at 4:53 AM James Henderson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="cremed">llvm-dev@lists.llvm.org</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">Hi all,<br><br>A broad goal of many of the LLVM binary tools, such as llvm-objcopy and llvm-objdump is to provide an alternative to the GNU equivalent, and as such, these tools have been developed to be command-line compatible. One tool where this hasn’t been the case up to now is llvm-readobj (aka llvm-readelf).</div></blockquote><div>I don't want to digress too much, but llvm-objdump isn't compatible either. For instance, "-df" is an llvm-objdump flag that accepts a list of functions to disassemble, but objdump accepts "-df" as a merged form of "-d -f" i.e. "--dissassemble --file-headers". So we may want to consider this as a meta-discussion for other tools like llvm-objdump.</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"><br>There was some discussion in <a href="https://reviews.llvm.org/D33872" class="m_1426986638061052804gmail-cremed m_1426986638061052804gmail-cremed m_1426986638061052804cremed cremed" target="_blank">https://reviews.llvm.org/D33872</a> about the purpose of llvm-readobj, so I’d like to ask the community's opinion. What is the purpose of llvm-readobj? Is it purely intended as an aid to testing? Should it be aiming to be GNU compatible, like most of the rest of the LLVM tools?<br></div></blockquote><div>From the source:</div><div><div>// This is a tool similar to readelf, except it works on multiple object file</div><div>// formats. The main purpose of this tool is to provide detailed output suitable</div><div>// for FileCheck.</div></div><div><br></div><div>My impression is that llvm-readobj is intended to provide information in the spirit of readelf, but not with any strong goal of keeping the format the same. Then, llvm-readelf (as a symlink wrapper) was added recently, to be more of a drop-in replacement, although still maybe not strict (same format, but maybe not char-for-char compatible). That's just what I've inferred from looking at code though, don't take my impression as judgement.</div><div><br></div><div>If that's the case, I think llvm-readelf should be relatively easy to make breaking changes to if it breaks in favor of increasing GNU readelf compatibility. llvm-readobj on the other hand has been around for a long time that folks might be relying on its flag parsing. I'd be happy if the latter were wrong and we could change llvm-readobj more freely though.</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"><br><div>The main issue I discovered with GNU compatibility is that llvm-readobj has a few incompatible command-line flags with different interpretations between the two tools:</div><br>* -s means dump symbols in GNU readelf, but dump sections in llvm-readobj<br>* -t means dump section details in GNU readelf, but dump symbols in llvm-readobj<br><div>* -a means dump all in GNU readelf, but dump arm attributes in llvm-readobj</div><br><div>There are also several missing aliases and some missing features, but we can implement those with no negative impact on the users of llvm-readobj, so I won't discuss those here.</div><div><br></div><div>Also of relevance here are long options preceded with only a single dash. My understanding of GNU’s behaviour is that each letter following it is treated as a different option, whereas in llvm-readobj, we get one single option (e.g. ‘readobj -abc’ would be equivalent to ‘readobj -a -b -c’, but ‘llvm-readobj -abc’ is equivalent to ‘llvm-readobj --abc’). This is at least partly related to the cl::opt/libOption issues discussed in <a href="http://lists.llvm.org/pipermail/llvm-dev/2018-October/127328.html" class="m_1426986638061052804gmail-cremed m_1426986638061052804gmail-cremed m_1426986638061052804cremed cremed" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2018-October/127328.html</a>).</div><div><br></div><div>I'd like to propose that we fix the three switches above such that they match GNU readelf's interpretation, and to change short-option handling similarly. This would inevitably result in some test churn (there are approximately 200 tests between core llvm and lld that would need updating), but it is manageable. More of an issue is that any users would suddenly find the switches changing on them, if they have started using llvm-readobj. On the other hand, I think the benefit for those used to GNU readelf outweighs the cost.</div></div></blockquote><div>+1</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><br></div><div>We could do a few different things to mitigate the impact of changing over, roughly in my order of preference, if we decide against just taking the plunge and changing the meaning:</div><div><br></div><div>1) For the next release, add a deprecation warning, saying that the switches’ meanings will be changed in a following release, and then fix it after the next release has been created, along with release notes documenting the change.
<div>2) Provide a “--gnu-mode” or similar switch that changes
 the meaning of the command-line switches above to match the GNU mode. 
This again provides an opt-in, but also allows downstream ports to 
enable it by default, should they wish.</div>

</div><div>3) Change the meaning of the switches only for llvm-readelf, and not for llvm-readobj. This is similar to the behaviour of --elf-output-style: it is GNU for llvm-readelf, and LLVM for llvm-readobj, but does have essentially the same potential for disrupting users as 1).</div><div>4) Provide a third user-facing driver (e.g. “llvm-gnu-readelf”) that provides a different CLI to the others. This makes it an opt-in feature, by using a different executable.</div><div>5) Just accept this divergence, although I personally would prefer not to, as this has the potential to confuse users migrating from GNU tools to LLVM tools.</div><br><div>Thoughts?</div></div></blockquote><div><br></div><div>(3) SGTM (that's the approach I went with in my patch)</div><div>(2) Sounds like it could get messy to have dependencies between flags, e.g. "--gnu-mode --help" and "--help" would have to be programmed to print different things for what "-s" is an alias of.</div><div>(1) Means we would need to wait until the next release (March?) to do anything? I'd rather not be tied down to slow release cycles :( [btw, does LLVM have a deprecation policy anywhere?]</div><div>(4) I could live with this if it came to it, but I think it's assuming that someone would want llvm-readelf and *not* want readelf compatibility, enough to outweigh all the people that want llvm-readelf to be like readelf -- who is that?</div><div>(5) I think we should veto this option -- this discussion means we clearly don't accept divergence :)</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"><br>James</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" class="m_1426986638061052804gmail-cremed m_1426986638061052804gmail-cremed m_1426986638061052804cremed cremed" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" class="m_1426986638061052804gmail-cremed m_1426986638061052804gmail-cremed m_1426986638061052804cremed cremed" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div></div></div>