llvm dev - Feb 2020 - compatibility with gnu binutils

>
> From: James Henderson via llvm-dev <llvm-dev at lists.llvm.org>
> To: Oliver Stannard <oliver.stannard at linaro.org>
> Cc: LLVM Dev <llvm-dev at lists.llvm.org>
> Subject: Re: [llvm-dev] [RFC] Case insensitive assembly directives for
>         all     targets
>
> +1 to all of what Oliver said. We aim for compatibility with GNU in most
> (all?) of our other binutils, so why should the assembler be any different?
>
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.

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?

Aside from the above query, case sensitive asm doesn't sound like a good
feature to me either.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200206/107074a1/attachment.html>

On Thu, 6 Feb 2020 at 00:24, Jon Chesterfield via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> From: James Henderson via llvm-dev <llvm-dev at lists.llvm.org>
>> To: Oliver Stannard <oliver.stannard at linaro.org>
>> Cc: LLVM Dev <llvm-dev at lists.llvm.org>
>> Subject: Re: [llvm-dev] [RFC] Case insensitive assembly directives for
>>         all     targets
>>
>> +1 to all of what Oliver said. We aim for compatibility with GNU in
most
>> (all?) of our other binutils, so why should the assembler be any
>> different?
>>
>
> 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.
>
> 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?
>
Many tools (readelf, objdump, nm, objcopy etc) are used in many people's
build systems, quite often in deep configure scripts that are hard to
maintain or update for whatever reason. There have been multiple talks on
this sort of topic at various LLVM conferences (examples include  Bernhard
Rosenkränzer and Jordan Rupprecht's talks at Brussels 2019), where people
have highlighted pain points. Additionally, I have been part of or run both
BoFs (again Brussels 2019) and round tables on the topic. The overwhelming
consensus from everyone there was that people wanted compatibility with GNU
to make it easier for them to switch over to using the LLVM tools. These
discussions were written up on the mailing list (see
http://lists.llvm.org/pipermail/llvm-dev/2019-April/132032.html and
https://lists.llvm.org/pipermail/llvm-dev/2019-April/132033.html for two
recent examples). The principle is discussed on multiple reviews of changes
for the tools too.

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.

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.

>
> Aside from the above query, case sensitive asm doesn't sound like a
good
> feature to me either.
>
> Thanks
> _______________________________________________
> 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/20200206/0bf2b64f/attachment-0001.html>

On Thu, Feb 6, 2020 at 9:15 AM James Henderson <jh7370.2008 at
my.bristol.ac.uk>
wrote:
>
> On Thu, 6 Feb 2020 at 00:24, Jon Chesterfield via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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.
>>
>
>> 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?
>>
> 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.
>
Thanks for your response. I read through the links but haven't gone looking
for diff reviews.

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.

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

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

Thanks,

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200206/98dee2ba/attachment.html>