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

[Rafael Avila de Espindola via llvm-commits]

Joerg Sonnenberger via llvm-commits <llvm-commits at lists.llvm.org>
writes:

> On Fri, Apr 14, 2017 at 03:56:06PM -0700, Rui Ueyama via llvm-commits wrote:
>> The peculiarity (or messiness) or MIPS ABI actually hurts MIPS-based
>> systems. Again, think about .gnu.hash sections. If your DSOs have .gnu.hash
>> sections, your dynamic symbols will be resolved quickly. That is important
>> for large modern programs that use a lot of DSOs. However, you cannot use
>> the feature on MIPS-based systems because the ABI forces some symbol
>> ordering in a way that is not compatible with .gnu.hash.
>
> I find it ironic that you would pick this example. I always found it a
> very peculiar choice for .gnu.hash to require ordering, compared to many
> of the alternative options of making the hash table significantly more
> useful. I.e. a system that stores the full hash and the symbol size in
> the hash table would very likely have highly similar skip rates without
> needing secondary bloom filters or forcing ordering in the symbol table.
> In fact, I find it quite dishonest to complain about MIPS ABIs using
> certain ordering requirements when the ABIs are older than the .gnu.hash
> mechanism.

The difference is that mips was the one architecture that had that
requirement.

Had it been an effort to improve all architectures (like .gnu.hash was),
this would not have been a problem.

Cheers,
Rafael