Re: [RFC] Add IFUNC support for MIPS (v3)

[Richard Sandiford <rdsandiford at googlemail dot com>]

Faraz Shahbazker <faraz.shahbazker@imgtec.com> writes:
> On 08/16/2015 12:17 PM, Richard Sandiford wrote:
>> We should probably report an error in cases where we see a global symbol
>> and the tag isn't defined, rather than silently mislink the code.
>
> A REL32 reloc with an IFUNC symbol could very well be for a data section.
> Though its safe to assume that there would be a corresponding relocation for
> the explicit GOT region as well, we wouldn't know which is which trivially,
> from inspecting the relocation. Wouldn't it look confusing if we check for the
> presence of GENERAL_GOTNO even for relocations that don't modify the general
> GOT region?

I was thinking that we should always have the DT_MIPS_GENERAL_GOTNO
if the DSO has a relocation against an ifunc.  There's no requirement
for DT_MIPS_GENERAL_GOTNO to be greater than 2 (i.e. for the new GOT
region to be nonempty).

The tag is really saying two things: there's a new region in the GOT
(possibly empty) and global symbols that feature in relocations no
longer need to be in the DT_MIPS_GOTSYM region.  The second is really
a prerequisite for the first.

Personally I wouldn't mind relaxing the DT_MIPS_GOTSYM rule unconditionally.
I just got the impression that others preferred the tools to reject objects
that don't follow the old ABI and don't explicitly request a new ABI feature.

Thanks,
Richard