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

[Rui Ueyama via llvm-commits]

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?

(Sorry for the balated response -- I was on vacation last week.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170424/9cb686e0/attachment.html>