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

[Simon Atanasyan via llvm-commits]

On Fri, Apr 14, 2017 at 10:57 PM, Rui Ueyama <ruiu at google.com> wrote:
> You wrote that we only have a few dozens of `if MIPS` statements, but we
> also have MIPS-specific classes and even a file that is dedicated for MIPS,
> although no other arch needs such things. This is not the first time for me
> to say that MIPS ABI is very odd (or I'd say messy). I'm making effort to
> help support MIPS, but as more MIPS-specific code and features are added,
> more I think this is too messy. Someone has to speak up that this really
> needs fixing. I don't want to blindly accept all these MIPS oddness without
> doing anything. I'm curious why you can't share information about the
> efforts that are currently being made to make the MIPS ABI more in line with
> other ELF ABIs.

That is a strange example of MIPS ABI's oddity. There are four MIPS-specific
classes in LLD. Except MipsGotSection three other classes are for .reginfo,
.MIPS.options, and .MIPS.abiflags sections. These sections contains
description of a file produced by the linker: used set of instructions,
used registers and their sizes, ISA extensions. I do not think that any
new MIPS ABI drops all these sections completely, because it's impossible
to hold all necessary data in the ELF header. Maybe future ABI, if it
is defined for all MIPS targets, will declare a single sections which
supersedes some or all of these sections on all MIPS architectures.

And I still cannot understand how these sections prevent making LLD
code better, faster, cleaner.

> On Fri, Apr 14, 2017 at 5:36 AM, Simon Atanasyan <simon at atanasyan.com>
> wrote:
>>
>> You say that MIPS ABI is always the largest roadblock. Why I have
>> never listened from you or somebody else something like "I try to
>> refactor this code but MIPS specific part prevents me to do this" or
>> "I reorganized this code and made it cleaner but now some MIPS tests
>> failed"?
>>
>> LLD code contains ~20 "if (Config->EMachine == EM_MIPS)" statements
>> for ~20000 lines of LLD code. Some of this "if" are just for adding
>> MIPS specific dynamic table entries and for definition of MIPS
>> specific symbols. Am I the only who do not think that it's
>> unacceptable price for supporting one more widely used architecture by
>> LLD? In fact, more than one architecture because MIPS32 / MIPS64 can
>> be considered as a separate targets.

-- 
Simon Atanasyan