libatomic IFUNC question (arm & libat_have_strexbhd)

[Richard Henderson]

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~