[Bug libgcc/60790] libatomic convenience library selects IFUNC implementation before obtaining cpu info.

[nsz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790

--- Comment #9 from nsz at gcc dot gnu.org ---
i added an execution test that aborts on modern x86_64 when built as

cc -c -o main.o main.c
cc -Wl,-z,now -shared -fPIC -o lib.so lib.c -latomic
cc -Wl,-rpath=. -o main main.o lib.so -lpthread -latomic

because the library is bind now, its function calls are resolved before the
libatomic ctor is run (so uses locking load_16/store_16), main is resolved
lazily so it is after the ctor (so uses cmpxchg16).

if in the same process libatomic ifunc can resolve to inconsistent
synchronization function in different modules that's broken behaviour.

note that an ifunc resolver has to be as-safe and thread-safe, so the attached
patch has to be checked to initialize edx atomically.
(i think it can be still broken if there is no direct DT_NEEDED dependency
against libatomic from a library that uses libatomic calls: libatomic may not
be relocated when the resolver in it is called)

there are several targets that do not support ifuncs at all and it seems even
where it is supported (glibc only) there are these issues so i'd prefer a
solution where gcc can be built without ifunc in libatomic (currently that is
broken too because libatomic has no fallback dispatch mechanism and gcc can
decide to inline cmpxchg16).