This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libatomic IFUNC question (arm & libat_have_strexbhd)
On 06/07/2017 01:31 PM, Florian Weimer wrote:
With lazy binding, the constructors of libraries should run in graph
dependency order, which means this constructor should run before any
users.
Except when another shared object uses the function from its own ELF
constructor, and the libatomic constructor has not yet run. This
should not happen if the object has a proper DT_NEEDED reference on
libatomic, but strange things happen once LD_PRELOAD is involved.
True, but that's relatively rare.
(There might also exist relocations which cannot be lazily bound, even
if the object wasn't linked with BIND_NOW.)
Once upon a time, we didn't really have a way to get at either
AT_HWCAP or AT_PLATFORM from here. Since then, glibc has grown the
getauxval function.
getauxval does not work from IFUNC handlers because it itself requires
a relocation (which may not have been processed at this point), and it
relies on global data which might not have been initialized.
Which is why I didn't actually call getauxval from the IFUNC resolver, but rely
on a data member being initialized.
And when the data member isn't initialized, for the various ordering issues
described above, the only consequence is that we use a less efficient (but not
incorrect) mechanism for the atomic.
It's possible we could do slightly better vs ordering with DT_PREINIT, but far
more common is DF_BIND_NOW, and no form of constructor helps with that.
I think we would have to pass ways to reach the relevant data as IFUNC
resolver arguments, and in addition fix the relocation processing in
ld.so to delay IFUNC resolution after all other relocation processing.
(I have an unfinished patch for the latter; I posted it to libc-alpha
a while back.)
That would be an improvement, yes.
r~