<div dir="ltr"><div>Hi Jake,</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>The options parsing code isn't very amenable to having different options
 and help messages for different aliases. It is actually possible to 
dynamically allocate the options so it's not impossible but it's a 
hassle and I'm not sure that it's what we want to do.</div></blockquote><div><br></div><div>We actually already do this to some extent in llvm-readelf/llvm-readobj, in that some options are configured at run time based on tool name, to allow for some aliases meaning different things between the two tools. I think it would be straightforward enough to use the "HideUnrelatedOptions" method to hide the Mach-O and COFF options. It would also be a good opportunity to group the options in llvm-readobj's help text according to file format.</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>Switching over to TableGen. <br></div></blockquote><div><br></div><div>I think you didn't finish this sentence? I'm guessing you were going to say that switching over to TableGen might be a good idea, or something like that. I'm not opposed to this, if somebody wants to give it a try. However, I don't think it would be a good idea for us to have two unrelated sets of options in llvm-readobj and llvm-readelf, that share the same code - I'd at least want the common options to be defined in only one place. At least within tests, I tend to use the two interchangeably, and it would be very confusing if there are switches without a common way of specifying them (as it is I almost always use the long-form --section-headers or --sections options because of the -s/-S/-t issue), and splitting them up too much might make the situation worse (as well as causing things like help text to rot in one set).<br></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>If we do solve this then we should take this opportunity to fix issues 
with things like `--dyn-syms` to make the two tools properly command 
line compatible which is an issue I personally hit a lot when I switch 
between using `llvm-readelf` and `readelf` <br></div></blockquote><div><br></div><div>Could you clarify what you mean here? I thought I'd caught all the different readelf aliases that weren't previously supported by llvm-readelf + llvm-readobj.</div><div><br></div><div>James<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 1 Jul 2019 at 19:35, Jake Ehrlich <<a href="mailto:jakehehrlich@google.com">jakehehrlich@google.com</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">llvm-readelf should not show any non-ELF options and should probably fail on non-ELF input IMO.<br><br>There are two things preventing this. One is the build system and the other is the is the options parsing code. The options parsing code isn't very amenable to having different options and help messages for different aliases. It is actually possible to dynamically allocate the options so it's not impossible but it's a hassle and I'm not sure that it's what we want to do. Switching over to TableGen. <a class="gmail_plusreply" id="gmail-m_7500154538548996344plusReplyChip-0" href="mailto:phosek@google.com" target="_blank">+Petr Hosek</a> my local CMake expert wasn't able to figure out how to build multiple tools in the same tool repo to allow for easy code sharing at the time we made llvm-strip. He might know now however. This too has a workaround I think because you can import code from parallel directories it's just not really a path that's ideal to go down. I think we need to support `llvm-readobj -elf-output-style=GNU` no matter what and it would be ideal if `llvm-readelf` where consistent with that so at the very least we want the same code to be used to do the printing for both. What options are used or output is another story. We have multiple ways to make the options and help messages different but all of them are headache's IMO.<br><br>If we do solve this then we should take this opportunity to fix issues with things like `--dyn-syms` to make the two tools properly command line compatible which is an issue I personally hit a lot when I switch between using `llvm-readelf` and `readelf`</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 1, 2019 at 2:55 AM James Henderson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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"><div>Hi Alex,</div><div><br></div><div>It's worth noting that the "alias" nature is really an implementation detail of the tools. There is nothing stopping us within the build process producing a completely separate executable (indeed, I think, though I'm not certain, that essentially this is what happens on Windows). Some tools (e.g. llvm-strip and llvm-objcopy) intentionally have a different set of options, and indeed the other options aren't even available.</div><div><br></div><div>I personally am against having "hidden" options documented in either form. They should be either hidden in all forms or nowhere (except possibly --help-hidden). Hidden options should, in my opinion, be limited to a) options that are irrelevant to the tool, b) options that are experimental and not ready for use, or c) options intended only for those in the know about how to use them. I'd argue that the llvm-readelf Mach-O/COFF options fall under a), since llvm-readelf is intended to be a GNU readelf equivalent, which doesn't support these switches, and they don't have any use for ELF objects. Users who wish to dump Mach-O and COFF output should be using llvm-readobj. Additionally, as noted in my original email, many people will be migrating from GNU readelf to llvm-readelf, and may find the large number of extra switches irrelevant, making it harder to interpret the help output.</div><div><br></div><div>James<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 29 Jun 2019 at 07:28, Alex Brachet-Mialot <<a href="mailto:alexbrachetmialot@gmail.com" target="_blank">alexbrachetmialot@gmail.com</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>My personal preference is that llvm-readelf only show the elf related options with -help and show all with -help-hidden. There is support for this in CommandLine.h, but I don't know how tricky it gets when we don't want them to be hidden for llvm-readobj. I haven't looked into this fully.<br></div><div><br></div><div>For some reference, I have compiled how the other alias tools are handled. Many of these are aliases to llvm-ar, it is helpful to know that llvm-ar doesn't use CommandLine.h to parse its options.<br></div><div><br></div><div>llvm-addr2line -> llvm-symbolizer: help is the same, docs mention it is an alias and only note the differences between it and llvm-symbolizer.</div><div>llvm-dlltool -> llvm-ar: help is different and -help-hidden changes nothing. I couldn't find docs for llvm-dlltool.<br></div><div>llvm-lib -> llvm-ar: *no* help option for llvm-lib. The docs don't even have a see also for ar.</div><div>llvm-ranlib -> llvm-ar: help is different. Docs mention it is an alias and note the differences.</div><div>llvm-strip -> llvm-objcopy: help is slightly different. Docs do not mention it is an alias.</div><div><br></div><div>The lack of a pattern makes some sense given different tools will have different requirements. Perhaps a useless widening of the scope of your question then. But back to your question, I personally think that a man page has the room to include _hidden_ options and don't see any benefit in excluding them. I also think it makes sense to mention it is an alias in the man page because it is a little curious otherwise why something called readelf has so many options for non elf files, in my opinion.</div><div><br></div><div>Best,</div><div>Alex<br></div></div>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>