[lld] Hiding original type of GOT related relocations

Hi,

There are more than one MIPS relocations which need GOT entry
creation. Let's consider two of them R_MIPS_GOT16 and R_MIPS_CALL16
[1]. R_MIPS_GOT16 is applicable to local and external symbols and
performs a different calculation in each cases [2]. R_MIPS_CALL16 is
applicable to external symbols only and a linker should show an error
if it finds R_MIPS_CALL16 with a local target. Now LLD in the
`InputSectionBase<ELFT>::relocate` methods hides original type of GOT
relocations and always use the result of `Target->getGotRefReloc()`
call. In case of MIPS it is R_MIPS_GOT16. It makes impossible to
perform target symbol type checking and the error generation in the
`MipsTargetInfo<ELFT>::relocateOne` method.

Is it really necessary to hide original relocation type? If a target
has multiple GOT related relocations it might just add more `cases` to
its `relocateOne` method.

[1] ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf page 4-19
[2] ftp://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf page 4-20

Hi,

There are more than one MIPS relocations which need GOT entry
creation. Let's consider two of them R_MIPS_GOT16 and R_MIPS_CALL16
[1]. R_MIPS_GOT16 is applicable to local and external symbols and
performs a different calculation in each cases [2]. R_MIPS_CALL16 is
applicable to external symbols only and a linker should show an error
if it finds R_MIPS_CALL16 with a local target. Now LLD in the
`InputSectionBase<ELFT>::relocate` methods hides original type of GOT
relocations and always use the result of `Target->getGotRefReloc()`
call. In case of MIPS it is R_MIPS_GOT16. It makes impossible to
perform target symbol type checking and the error generation in the
`MipsTargetInfo<ELFT>::relocateOne` method.

I guess there's no need to hide the type. It's just that because it works
for x86, x86-64 or aarch64. If mips requires more info, it should be ok to
change that.

Hi,

There was no support for GOT relocations for the AArch64 target. I’m adding it with . I faced the similar problem, so I extended the getGotRefReloc() method in this patch.

Thanks for your replies, advice and fix.