[llvm-dev] RFC: llvm-readelf Mach-O & COFF options

Tue Jul 2 01:28:56 PDT 2019

Hi Jake,

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.
>

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.

Switching over to TableGen.
>

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).

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`
>

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.

James

On Mon, 1 Jul 2019 at 19:35, Jake Ehrlich <jakehehrlich at google.com> wrote:

> llvm-readelf should not show any non-ELF options and should probably fail
> on non-ELF input IMO.
>
> 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. +Petr Hosek <phosek at google.com> 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.
>
> 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`
>
> On Mon, Jul 1, 2019 at 2:55 AM James Henderson via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Alex,
>>
>> 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.
>>
>> 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.
>>
>> James
>>
>> On Sat, 29 Jun 2019 at 07:28, Alex Brachet-Mialot <
>> alexbrachetmialot at gmail.com> wrote:
>>
>>> 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.
>>>
>>> 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.
>>>
>>> llvm-addr2line -> llvm-symbolizer: help is the same, docs mention it is
>>> an alias and only note the differences between it and llvm-symbolizer.
>>> llvm-dlltool -> llvm-ar: help is different and -help-hidden changes
>>> nothing. I couldn't find docs for llvm-dlltool.
>>> llvm-lib -> llvm-ar: *no* help option for llvm-lib. The docs don't even
>>> have a see also for ar.
>>> llvm-ranlib -> llvm-ar: help is different. Docs mention it is an alias
>>> and note the differences.
>>> llvm-strip -> llvm-objcopy: help is slightly different. Docs do not
>>> mention it is an alias.
>>>
>>> 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.
>>>
>>> Best,
>>> Alex
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190702/b2c0b79e/attachment.html>