Re: [PATCH v2 2/6] arm64: HWCAP: add support for AT_HWCAP2

[Andrew Murray <andrew.murray@arm.com>]

On Wed, Mar 27, 2019 at 03:02:25PM +0000, Andrew Murray wrote:
> On Fri, Feb 22, 2019 at 10:35:01AM +0000, Szabolcs Nagy wrote:
> > On 21/02/2019 18:45, Dave P Martin wrote:
> > > For ABI purposes, we should take the opportunity to document the status
> > > of the currently unused bits.
> > > 
> > > For interoperation with the glibc ifunc resolver ABI, we may want to
> > > reserve a bit among AT_HWCAP [63:32] or AT_HWCAP2 [31:0] that will
> > > never be used by the kernel and always passed to userspace as 0.
> > 
> > if hwcap2 is introduced at bit 32, i'd expect the top 32 bits
> > of hwcap1 to be 0 on lp64 (and thus libc may use those bits
> > for something internally or in the ifunc abi).
> > 
> > > I'm envisaging code such as
> > > 
> > > 	foo resolver(unsigned long hwcaps, unsigned int num_at_hwcaps,
> > > 			unsigned long const *at_hwcaps)
> > > 	{
> > > 		if ((hwcaps & _GLIBC_EXTRA_HWCAPS) &&
> > > 				num_at_hwcaps >= 2 &&
> > > 				at_hwcaps[1] && HWCAP2_FOO)
> > > 			/* feature present */
> > > 	}
> > > 
> > > We would need that _GLIBC_EXTRA_HWCAPS to distinguish the second and
> > > third arguments from uninitialised junk that would be passed by older
> > > glibc versions.
> > 
> > yes, i plan to do such a change.
> > 
> > > Glibc might or might not choose to try and wegde AT_HWCAP2 in the top
> > > bits of the first argument instead of bits [63:32] of AT_HWCAP (which
> > > we expect to be zero for now, but could still be made reachable via the
> > > at_hwcaps pointer).
> > 
> > the public api via getauxval and hwcap macro defines
> > will not do tricks that break lp64 vs ilp32 portability.
> > (that would defeat the purpose of hwcap2)
> > 
> > > Coordination would be needed if glibc carries on using the
> > > <uapi/asm/hwcap.h> HWCAP{,2}_foo defines for here while doing tricks
> > > of this sort.
> > > 
> > > Szabolcs may have a view on whether this is needed / useful.
> > 
> > for now coordination is not needed, glibc does not
> > use uapi hwcap.h directly, but copies it and it won't
> > do tricks that change hwcap values anyway, only adds
> > one new flag for ifunc resolvers.
> > 
> > > If so, we should document any required guarantees now so that we don't
> > > accidentally violate them during future maintenance.  For the benefit
> > > of userspace folks, it may be a good idea to have some clear statement
> > > in Documentation/arm64/ also.
> > 
> > on lp64 glibc will expect hwcap top 32bit to be 0.
> > this can be changed in the future if we no longer
> > care about ilp32 and at that point we may need
> > some coordination between linux and glibc so
> > the ifunc resolver abi does not break.
> > 
> > > Because of the ABI implications here, if would also be good idea to copy
> > > the libc-alpha mailing list, and possibly also linux-api.
> > 
> > yes.
> 
> I'll add documentation to Documentation/arm64 to indicate that the upper 32bits
> of AT_HWCAP will always be 0. Is this correct? 

How about this (in Documentation/arm64/elf_hwcaps.txt)?

+
+
+4. Unused AT_HWCAP bits
+-----------------------
+
+Each AT_HWCAP and AT_HWCAP2 entry provides for up to 32 hwcaps contained
+in bits [31:0]. For interoperation with userspace we guarantee that the
+top bits [63:32] of AT_HWCAP will always be returned as 0.

Thanks,

Andrew Murray

> 
> Thanks,
> 
> Andrew Murray
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel