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

[Simon Atanasyan via llvm-commits]

On Tue, Apr 25, 2017 at 5:31 AM, Rui Ueyama <ruiu at google.com> wrote:
> On Thu, Apr 20, 2017 at 3:16 AM, Simon Atanasyan <simon at atanasyan.com>
> wrote:
>>
>> On Wed, Apr 19, 2017 at 3:19 PM, Rui Ueyama <ruiu at google.com> wrote:
>> > But MIPS multi-GOT is not integrated well as other parts of the system,
>> > no?
>> > It seems that it tried to avoid making any changes to the system. It
>> > doesn't
>> > use any help from dynamic linker other than the regular dynamic
>> > relocation
>> > processing. So we have to generate more dynamic relocations than
>> > necessary
>> > to simulate what the dynamic linker would do for the real GOT.
>>
>> As far as I understand at the time of initial multi-GOT implementation
>> there
>> were two solutions. The first one - perform all modifications in a static
>> linker. The second one - modify both static and dynamic linkers.
>> Complexity
>> are equal in both cases. In the second case it is just spread among two
>> components. The first solution allows linking of large files and running
>> such files on any systems at the price of worse loading time for large
>> executable files. The second solution provides better loading time, but
>> requires upgrading of system dynamic linkers. Probably keeping all changes
>> in a static linker provides more benefits and this approach has bee
>> chosen.
>>
>> Now I do not know about large amount of end-user requests on loading time
>> reducing so it is still not a good idea to broke compatibility and
>> redesign
>> dynamic linker at least for that part of ABI.
>
> But they could have done both -- they could have made a temporary change to
> the static linker and also improved the dynamic linker, no? It seems to me
> that that is another instance of the habit to overly avoid changing the
> loader at all. It looks like MIPS systems are frozen more than a decade ago,
> and nobody seems to make any changes to it anymore. Why?

They could, but probably benefits from the dynamic linker modification are
less than disadvantage: increase code complexity, necessity to distinct
new/old binaries by the dynamic linker etc. It is not my opinion. I just
try to figure out motivation of MIPS community.

You are right, MIPS ABIs have not significantly changed for a long time.
There was an attempt to suggest a replacement - MIPS NUBI [1] which is
discussed from time to time, but as far as I know even a prototype
implementation have never been released. There are some additional rarely
used ABIs like o64 and MIPS eabi. There are some unimplemented proposals
and implemented extensions to MIPS ABI. For example, "MIPS support for
--hash-style=gnu" [2] or "Compact Exception Tables for MIPS ABI".

Unfortunately I do not have an answer on the question - why there is no new
MIPS ABI. Inventing, implementation and making such ABI widely used
are difficult
tasks, especially the last one. Maybe the reason is multiple number of
existing ABIs, large number of different users of existing ABIs, tight
relation between ABI's and MIPS hardware specifics etc.

[1] https://dmz-portal.mips.com/mw/images/9/93/MD00438-2C-NUBIDESC-SPC-00.20-1.pdf
[2] https://sourceware.org/cgi-bin/search.cgi?wm=wrd&form=extended&m=all&s=D&q=neschell&ul=%2Fml%2Fbinutils%2F%25
[3] https://github.com/itanium-cxx-abi/cxx-abi/blob/master/MIPSCompactEH.pdf

-- 
Simon Atanasyan