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

[Rui Ueyama via llvm-commits]

On Sun, Apr 30, 2017 at 10:02 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> 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 agree that we eventually have to check this in, but what I'm trying to do
is to understand the situation and and ask why why MIPS ABI has not been
updated so long. It seems MIPS ABI is very conservative while ABIs for
other architectures are not that much. I could imagine a few examples (lack
of clear ownership of the ABI?) but no one really seem to answer my
question.

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

That is a valid concern and should be answered by people from the MIPS
community. To me, it seems they should make a change to their ABI at least
for the .gnu.hash section.

-- 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/20170502/5634dd79/attachment.html>