This is the mail archive of the
mailing list for the GCC project.
Re: libatomic IFUNC question (arm & libat_have_strexbhd)
- From: Steve Ellcey <sellcey at cavium dot com>
- To: Richard Henderson <rth at redhat dot com>, Florian Weimer <fw at deneb dot enyo dot de>, Jim Wilson <jim dot wilson at linaro dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 07 Jun 2017 13:22:23 -0700
- Subject: Re: libatomic IFUNC question (arm & libat_have_strexbhd)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=cavium.com;
- References: <201706052232.v55MW7Jj022346@sellcey-dt.caveonetworks.com> <email@example.com> <firstname.lastname@example.org>
- Reply-to: sellcey at cavium dot com
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Wed, 2017-06-07 at 12:21 -0700, Richard Henderson wrote:
> > 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
Would defining __builtin_cpu_init, __builtin_cpu_is,
and __builtin_cpu_supports for ARM help with this? X86 seems to have
some special code to call __builtin_cpu_init
from dispatch_function_versions. Is that early enough? Then
__builtin_cpu_is or __builtin_cpu_supports could be used in the IFUNC
resolvers instead of checking the libat_have_strexbhd variable.