Re: [Mips}Using DT tags for handling local ifuncs

[Richard Sandiford <rdsandiford at googlemail dot com>]

Jack Carter <Jack.Carter@imgtec.com> writes:
> I finally figured out the disconnect and it is me. 
>
> I worked at SGI for a very long time. I worked on the linker and implemented
> their multigot. SGI did different things with the GOT than GNU.
>
> SGI would mark in the got regions for INTERNAL, HIDDEN and PROTECTED
> entries and keep the symbol reference to them. I believe they stayed in the
> .dynsym table, but kept their STO visibility markings. I could dump the got
> and get symbolic information.
>
> GNU doesn't do this. They say that internal, hidden and probably protected
> are locals and just need the loadtime fixup value to make them right and thus
> don't need to refer to any symbols.
>
> Neither is wrong, just a bit different.
>
> Thus for GNU, to fixup the ifunc entries in the local got I need to
> partition it from the other local got entries and have explicit
> offsets to at least the old local got region, the new ifunc local got
> region and maybe even the global got region in case there are future
> got region shuffling and or additions.

Personally I'd rather not define an ifunc region per se.  The idea behind
making the start of the "ABI-defined" local GOT explicit was that the GOT
entries before that could be relocated using normal relocations rather than
the implicit scheme (as most other targets do).  The advantages of that
to me are:

(a) It means no other extensions are needed in future if we need a fourth
    type of GOT relocation (on top of the implicit R_MIPS_REL* for
    local entries, the implicit R_MIPS_{32,64} for global GOT entries
    and the new R_MIPS_IRELATIVE).

(b) It preserves the current scheme in which the ABI-defined part of the
    GOT is relocated first.  If we had an ABI-defined ifunc region we would
    need to go back and relocate it after processing the explicit relocations,
    so it would logically be a new step.

(c) It means that the explicit GOT relocations can be sorted with
    the other relocations.  This could be useful if priorities are
    ever added to ifuncs (like how constructors and destructors
    can have priorities).

(d) It leaves open the possibility of reserving entry 2 in future,
    in a similar way to entry 1 is reserved now.

I think it's less work too.  We need to get bfd to mark out the new
region either way, so both schemes should have equal complexity there.
But relocating the start of the GOT normally would be less work for
other tools.  E.g. the dynamic linker change I mentioned in my earlier
reply.  But...

> Is there a preference for the ifunc local got to be before the regular
> local got or after?

...it seems like you're still rejecting that idea. :-)

OTOH, the same problem applied when TLS was added: the TLS GOT entries
needed to be explicitly relocated.  What happened then was that the
entries were added after the global GOT.  I suppose that avoided the
new tag, but the disadvantage is that it can force multi-GOTs to be
used unnecessarily.  Especially since the global GOT needs to contain
all symbols that have relocations against them, even if there are no
GOT accesses to them.  But I could live with irelative relocations
being handled this way too if you prefer.

Thanks,
Richard