[PATCH] D31528: [ELF][MIPS] Multi-GOT implementation

[Sean Silva via llvm-commits]

On Wed, Apr 26, 2017 at 6:57 AM, Rui Ueyama via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> I think I disagree. As I wrote there are still a lot of unnecessary
> divergences from the other ELF standards in the MIPS ABI, and in a long
> run, I believe these issues should be addressed, even if it means we need
> more code in a (possibly long) transition period.
>

I think we should first and foremost focus on making LLD a production MIPS
linker for today's environment. For example, making LLD be /usr/bin/ld for
FreeBSD on MIPS.

The ABI is a very cross-functional thing, involving kernel (x N OS's),
dynamic linker/loader (x N libc's), static linker (x N static linkers),
compiler (x N compilers), MC/assembler (x N assemblers), package management
(x N distros), and other components (and there is likely not a perfect
mailing list where active maintainers of all affected components are
reading, making the organizational complexity extremely large). The costs
of such a transition could easily enter into the millions of dollars of
engineer time (including user time, as some things are likely to be
incompatible). Speaking for myself as an LLD developer, I don't think it's
appropriate for LLD developers to be making requests to change an ABI that
we don't even implement at production quality.

It sounds like we're pretty close to supporting MIPS at production quality,
so I think we should move forward with that. Once that is done, we can
concretely evaluate what things we want to be changed. I don't think it's
worth even starting a discussion right now.

My 2 cents: I suspect that once we do support MIPS at production quality,
we'll look at all the MIPS-specific code in LLD and say "this is annoying,
but not bad enough to be worth churning the world with a new ABI". (i.e.,
it's a "frog in boiling water" situation, but the water is only at 35
degrees C and not rising at a significant rate)




> I believe, for example, we can agree that the very odd middle-endian
> header should have been fixed like 10 years ago.
>

I think that 10 years ago it was probably clear that the middle-endian
header was undesirable and annoying, but I don't think it's at all obvious
that 10 years ago a transition should have been started in order to change
it; the costs of doing that are enormous and probably not worth it. We
would probably be stuck in a situation like .ctors/.dtors vs
.init_array/.fini_array -- 10+ years later, we still have to support both,
with no indication that we will ever be able to delete support for one of
them (like the xkcd comic that Joerg posted).

I think you would agree that making a new MIPS ABI just to end up in a
situation like .{c,d}tors/.{init,fini}_array would just make things worse
for us. What makes you so sure that that isn't going to happen? Is it worth
the risk?

-- Sean Silva


> I understand that it is of course not your fault. Who is maintaining the
> MIPS ABI?
>
> On Wed, Apr 26, 2017 at 3:17 AM, Simon Atanasyan <simon at atanasyan.com>
> wrote:
>
>> I do not think that hypothetical MIPS ABI will be _much_ _more_
>> similar to other ABIs. For example, as to me I would keep MIPS GOT
>> almost the same because it's efficient and works well. Even if a
>> dynamic linker starts to recognize multi-GOT, that removes only a few
>> lines of code from LLD. And during a long transition period we will
>> have to support both variants. Special rules for .dynsym ordering and
>> unsupported --hash-style=gnu are tightly related to MIPS GOT. There is
>> an oddity in calculation addends for "paired" relocations (R_MIPS_HI16
>> / R_MIPS_LO16) but we can consider this issue as fixed in N32 and N64
>> ABI. Special sections like .reginfo, .MIPS.options, and .MIPS.abiflags
>> are required to describe varieties of MIPS hardware. It's possible to
>> rename default entry symbol s/__start/_start/, but it will not make
>> LLD code much cleaner.
>>
>> In general, requirement to remove incompatibilities from MIPS ABI
>> looks like a requirement to make MIPS ISA more similar to say X86 ISA
>> for simplification of LLVM MC library code base. MIPS requires new ABI
>> and finally I think it gets the new ABI, but I do not expect that this
>> makes LLD code base smaller and cleaner.
>>
>> On Tue, Apr 25, 2017 at 7:37 PM, Rui Ueyama via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>> > Simon, can you start a discussion in the MIPS ABI mailing list (if
>> exists)
>> > that you are getting a push-back due to the incompatibilities from
>> other ELF
>> > standards?
>>
>> --
>> Simon Atanasyan
>>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170430/9c81b4c4/attachment.html>