[lld] r257023 - [ELF] Add AMDGPU support

[Matthew Fortune via llvm-commits]

Simon Atanasyan <simon at atanasyan.com> writes:
> On Wed, Jan 20, 2016 at 3:17 AM, Rui Ueyama <ruiu at google.com> wrote:
> > On Tue, Jan 19, 2016 at 4:06 PM, Rafael Espíndola
> > <rafael.espindola at gmail.com> wrote:
> >>
> >> > I agree that MIPS is unusual architecture from the linker point of
> >> > view. But other linkers like gold and mclinker have not too
> >> > complicated design, fast and support MIPS together with other
> targets.
> >> > I do not have ready solution for LLD but maybe ability to create
> >> > target specific GOT sections, override iteration over relocations
> >> > etc allow to isolate unusual MIPS code and does not pollute common
> code.
> >>
> >> Sorry for not being clear, most of the pain I see is on the llvm side
> >> (where r_info parsing is done and we have the joy of handling the
> >> ABIs and their implementations in bfd).
> >
> > Who owns the MIPS ABI? Is there any ratification process or something
> > if we want to update the ABI to flush out the oddities?
> 
> Matthew, please correct me if I am wrong, but AFAIK there is no single
> owner of MIPS ABI and any formalized process of ABI modifications. A
> good example is a discussion about MIPS support for --hash-style=gnu.
> 
> https://sourceware.org/ml/binutils/2015-10/msg00057.html

Essentially Simon is correct. As owners of the MIPS architectures the
engineers at Imagination aim to steer and unify the needs of various
communities stretching from GNU, Linux kernel, *BSD, LLVM, custom
MIPS hardware extensions and anything related. The defacto definition
of the MIPS ABI is the GNU implementation and the overriding rule is
to maintain compatibility while planning for longer term changes that
could take years to migrate through. What this means is that there has
to be a route to an ABI change that does not result in all MIPS binaries
simply not working one day. New tools can and should start from an ABI
that is common today and need not look too far back in history but
there are no quick fixes here.

To make that a little less vague I think it is reasonable to assume
the following maintainers should be consulted for ABI change:

binutils) Maciej Rozycki (macro at imgtec.com)
glibc)    Joseph Myers (joseph at codesourcery.com)
gcc)      Matthew Fortune <Matthew.Fortune at imgtec.com>
          Moore, Catherine (Catherine_Moore at mentor.com)
Linux)    Ralf Baechle (ralf at linux-mips.org, Ralf.Baechle at imgtec.com)
LLVM)     Daniel Sanders <Daniel.Sanders at imgtec.com>

And for architecture steering:

          Rich Fuhler <Rich.Fuhler at imgtec.com>

While this list is heavily dominated by Imagination employees, in this
capacity we are acting on behalf of the communities we support rather
than simply Imagination.

Hope that is useful.

Thanks,
Matthew