<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 19, 2016 at 1:47 PM, Simon Atanasyan <span dir="ltr"><<a href="mailto:simon@atanasyan.com" target="_blank">simon@atanasyan.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jan 20, 2016 at 12:18 AM, Rafael Espíndola<br>
<<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
> A thought that has been growing in my mind for some time: There has to<br>
> be a limit to how odd a system we support on trunk. If someone<br>
> proposes a backend that use PDP endian, 9 bit bytes and cray floats I<br>
> think we should just reject it.<br>
><br>
> The main thing that started me thinking was MIPS, were there seems to<br>
> be an endless series of differences to compensate for some other<br>
> difference. IMHO it and LLVM would be better served by having by<br>
> having a clean V2 ABI on trunk and all of odd st_info, relocation<br>
> packing, hi/lo mapping in a vendor branch.<br>
<br>
</span>I agree that MIPS is unusual architecture from the linker point of<br>
view. But other linkers like gold and mclinker have not too<br>
complicated design, fast and support MIPS together with other targets.<br>
I do not have ready solution for LLD but maybe ability to create<br>
target specific GOT sections, override iteration over relocations etc<br>
allow to isolate unusual MIPS code and does not pollute common code.<br>
<br>
Sure that does not mean that I like current MIPS ABI :)<br></blockquote><div><br></div><div>I'm pretty sure that you don't necessarily like the current MIPS ABI. :) As for me, I dislike part of the MIPS ABI which are different from the mainstream ELF ABIs without any justifiable reason. The MIPS endian looks really a baked in bug that happened to be in the early version of some Unix for MIPS (I've never seen any mixed endian format in the wild except the MIPS ELF.) It doesn't support .gnu.hash. It has odd HI/LO relocations, etc, etc.</div><div><br></div><div>We indeed want to support the current MIPS ABI since that's after all the current ABI, and I really appreciate your effort. However, beside that, I think there should be some effort going on to update the ABI to resolve the issues.</div></div></div></div>