Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

[Roland McGrath <roland at redhat dot com>]

> 1. A STT_GNU_IFUNC function should never access any data which need
> relocation.

This does not seem like too much of a constraint, given that it also
unavoidably has to work before the DSO's initializers have run.
i.e., it is always special-purpose code that has to be written very
carefully.  Being PIC code it should not be relying on much to have been
done before.  It just has to avoid any PLT calls or other GOT use itself.

> 2. Dynamic relocations against STT_GNU_INFUNC symbols should be
> placed after all other relocations.

This is not possible, is it?  Some DSO has a reference to "&strlen".
It has no idea that libc's definition will be STT_GNU_IFUNC.
The DSO might even have been linked against a libc.so that did
not use STT_GNU_IFUNC to define "strlen".

The only other alternative to #1 that I see is some scheme whereby "&func"
will in all cases resolve to a PLT entry rather than the actual
STT_GNU_IFUNC symbol's st_value.  i.e., the ifunc resolver is only called
for PLT resolution (and you can do all those last for BIND_NOW).

e.g. in the defining DSO make ld generate a PLT entry with second symbol a
la executables' PLT entries, and then have rtld ignore the STT_GNU_IFUNC
symbol when resolving non-PLT relocs.  (Seems highly dubious.)

But in fact any scheme with that result might be undesireable in practice.
If the executable does not refer to "&func", then we don't have the pointer
equality issue and so DSOs with function pointer tables pointing to other
DSOs' entry points would do the extra indirection of a PLT jump when it
could be avoided except for this initialization order question.


Thanks,
Roland