This is the mail archive of the
mailing list for the GCC project.
Re: libatomic IFUNC question (arm & libat_have_strexbhd)
On 06/05/2017 10:50 PM, Florian Weimer wrote:
* Steve Ellcey:
I have a question about the use of IFUNCs in libatomic. I was looking at the
arm implementation and in gcc/libatomic/config/linux/arm/host-config.h I see:
extern bool libat_have_strexbhd HIDDEN;
# define IFUNC_COND_1 libat_have_strexbhd
I also see that gcc/libatomic/config/linux/arm/init.c has:
static void __attribute__((constructor))
What I don't see is any place that libat_have_strexbhd would ever get
set. What am I missing here? init_cpu_revision is going to get called
when libatomic is first loaded since it is a constructor but it doesn't
seem to do anything and it isn't going to set libat_have_strexbhd as far
as I can see.
Setting the variable in the constructor wouldn't influence IFUNC
resolver behavior because those can run before ELF constructors
(even with lazy binding).
With lazy binding, the constructors of libraries should run in graph dependency
order, which means this constructor should run before any users.
Without lazy binding, you're right that ifunc resolvers can run earlier, and
this would be largely useless. Suggestions for a better organization welcome.
That said, this clearly is lacking some actual guts.
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.
As far as I can see, there's no AT_HWCAP bit that can help. We can get "v6" or
"v7" from AT_PLATFORM, from which we can infer strexd.
We don't seem to be able to infer v6t2, but I suspect we don't *really* need
that here, since the compiler *can* generate sub-word atomic accesses from
strex and we don't necessarily require strex[bh].
That said, real distributions targeting armhf are really targeting armv7, and
*all* of this IFUNC stuff is worthless overhead for that case. So it would be
better to avoid it all.