This is the mail archive of the
mailing list for the glibc project.
Re: [RFC 2.0] Implementing hwcap2
- From: David Miller <davem at davemloft dot net>
- To: roland at hack dot frob dot com
- Cc: vapier at gentoo dot org, libc-alpha at sourceware dot org, ryan dot arnold at gmail dot com, rth at twiddle dot net, rsa at us dot ibm dot com
- Date: Thu, 28 Mar 2013 20:10:48 -0400 (EDT)
- Subject: Re: [RFC 2.0] Implementing hwcap2
- References: <20130328 dot 173934 dot 1310725546115298719 dot davem at davemloft dot net> <201303281931 dot 43830 dot vapier at gentoo dot org> <20130328234033 dot 9197A2C0A7 at topped-with-meat dot com>
From: Roland McGrath <email@example.com>
Date: Thu, 28 Mar 2013 16:40:33 -0700 (PDT)
>> how ? resolve_* are not exported symbols, and they're not in the header files.
> Those are just the users of the changed ABI. The ABI in question is the
> convention by which the dynamic linker calls IFUNC resolver entry points.
> Richard quoted the an example of the affected callees because Ryan's change
> didn't change the callers, which are elf_ifunc_invoke in dl-irel.h. Those
> that pass GLRO(dl_hwcap) (arm, powerpc, s390, sparc) do so using a cast to
> a hand-written function pointer type, which takes 'unsigned long int' for
> arm, powerpc, and s390, and 'int' for sparc. Though GLRO(dl_hwcap) already
> has type uint64_t, the prototypes in those casts (for sparc, arm,
> powerpc32, and s390-32) will truncate the value being passed. So in fact,
> Ryan hasn't changed the ABI, but he intends to and needs to for the purpose
> of his change to take effect.
I'd rather not do this on Sparc.
IFUNC resolvers are written in assembler and shared between 64-bit and
If we change the hwcap argument type to be a uint64_t then on 32-bit
the argument will be passed differently compared to now where we can
always expect the low 32-bits of the hwcaps to be in %o0.