llvm dev - Jun 2019 - RFC: llvm-readelf Mach-O & COFF options

Hi all,

llvm-readelf is an alias for llvm-readobj which aims for GNU compatibility
and is likely the tool that most people migrating to the LLVM binutils will
adopt instead of llvm-readobj. Because it is just an alias, it has
inherited the functionality provided by llvm-readobj, including for non-ELF
targets, with Mach-O and COFF-specific switches available in its interface.
People migrating from GNU readelf won't need these switches.

I have a change up for review to expand the documentation for llvm-readelf
to list all its supported switches (see https://reviews.llvm.org/D63826).
This patch currently includes the Mach-O and COFF specific switches. It was
suggested that these could be surprising and unnecessary, and could be
removed from the patch. If we go ahead and remove them from the
documentation, I think we should remove them from the help text, or
possibly even the available options entirely. I'd be happy to do the work
for this, if the community agrees that llvm-readelf should only support
ELF-related options.

Thoughts?

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/286c5bab/attachment.html>

My perspective is that llvm-readobj is a testing tool whose goal should be
to make testing LLVM easy, not 100% GNU readelf compatibility, but I think
that ship has sailed.

I don't really care if you decide to move the functionality, I just want to
have some binary in LLVM for exploratory dumpers, where I don't have to
care too much about consistency with another tool that makes different
arbitrary formatting decisions. So, if you want to move it, I guess we need
some new binary where we can put experimental code. "llvm-objutil"
mirroring llvm-pdbutil?

On Thu, Jun 27, 2019 at 3:03 AM James Henderson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi all,
>
> llvm-readelf is an alias for llvm-readobj which aims for GNU compatibility
> and is likely the tool that most people migrating to the LLVM binutils will
> adopt instead of llvm-readobj. Because it is just an alias, it has
> inherited the functionality provided by llvm-readobj, including for non-ELF
> targets, with Mach-O and COFF-specific switches available in its interface.
> People migrating from GNU readelf won't need these switches.
>
> I have a change up for review to expand the documentation for llvm-readelf
> to list all its supported switches (see https://reviews.llvm.org/D63826).
> This patch currently includes the Mach-O and COFF specific switches. It was
> suggested that these could be surprising and unnecessary, and could be
> removed from the patch. If we go ahead and remove them from the
> documentation, I think we should remove them from the help text, or
> possibly even the available options entirely. I'd be happy to do the
work
> for this, if the community agrees that llvm-readelf should only support
> ELF-related options.
>
> Thoughts?
>
> James
> _______________________________________________
> 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/20190627/95f4f048/attachment.html>

llvm-readobj is fine as is, and as far as I know, there's no issue with it
needing to be GNU compatible. llvm-readelf on the other hand should be,
based on various discussions over the last couple of years. I'm not
proposing removing the Mach-O and COFF options from llvm-readobj at all. I
think it makes sense to keep them where they are. What I'm suggesting is
removing them from the options in llvm-readelf ONLY (detected by the name
of the executable, similar to how we already decide what aliases to
support). Ideally, I'd expect these options to still be available in
llvm-readelf, and they'd do exactly the same as what llvm-readobj does,
just that they wouldn't be printed by llvm-readelf --help.

To reiterate, this proposal does not affect the behaviour of the
llvm-readobj executable, unless it has been renamed to llvm-readelf. Does
that make sense?

James

On Thu, 27 Jun 2019 at 19:43, Reid Kleckner <rnk at google.com> wrote:
> My perspective is that llvm-readobj is a testing tool whose goal should be
> to make testing LLVM easy, not 100% GNU readelf compatibility, but I think
> that ship has sailed.
>
> I don't really care if you decide to move the functionality, I just
want
> to have some binary in LLVM for exploratory dumpers, where I don't have
to
> care too much about consistency with another tool that makes different
> arbitrary formatting decisions. So, if you want to move it, I guess we need
> some new binary where we can put experimental code.
"llvm-objutil"
> mirroring llvm-pdbutil?
>
> On Thu, Jun 27, 2019 at 3:03 AM James Henderson via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> llvm-readelf is an alias for llvm-readobj which aims for GNU
>> compatibility and is likely the tool that most people migrating to the
LLVM
>> binutils will adopt instead of llvm-readobj. Because it is just an
alias,
>> it has inherited the functionality provided by llvm-readobj, including
for
>> non-ELF targets, with Mach-O and COFF-specific switches available in
its
>> interface. People migrating from GNU readelf won't need these
switches.
>>
>> I have a change up for review to expand the documentation for
>> llvm-readelf to list all its supported switches (see
>> https://reviews.llvm.org/D63826). This patch currently includes the
>> Mach-O and COFF specific switches. It was suggested that these could be
>> surprising and unnecessary, and could be removed from the patch. If we
go
>> ahead and remove them from the documentation, I think we should remove
them
>> from the help text, or possibly even the available options entirely.
I'd be
>> happy to do the work for this, if the community agrees that
llvm-readelf
>> should only support ELF-related options.
>>
>> Thoughts?
>>
>> James
>> _______________________________________________
>> 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/20190628/55c6b6dd/attachment.html>