Re: [RFC PATCH] aarch64: new ifunc resolver ABI

[Florian Weimer <fweimer at redhat dot com>]

* Szabolcs Nagy:

> On 12/06/2019 11:51, Florian Weimer wrote:
>> * Szabolcs Nagy:
>> 
>>> Passing a second argument to the ifunc resolver allows accessing
>>> AT_HWCAP2 values from the resolver. AArch64 will start using AT_HWCAP2
>>> on linux because for ilp32 to remain compatible with lp64 ABI no more
>>> than 32bit hwcap flags can be in AT_HWCAP which is already used up.
>> 
>> Is the expectation that ilp32 will always have the second argument, and
>> therefore will not need the flag?
>
> i guess there is no backward compat issue on ilp32
> because it's not merged yet upstream,

Right.

> but currently ilp32 resolver takes uint64_t argument
> while AT_HWCAP is 32bit, so ilp32 resolver code can
> do the same _IFUNC_ARG_HWCAP flag check as lp64,
> before it uses the second argument.

I see.

>>> Old call ABI passed hwcap as uint64_t, new abi sets the
>>> _IFUNC_ARG_HWCAP flag in the hwcap and passes a second argument
>>> that's a pointer to an extendible struct. A resolver has to check
>>> the _IFUNC_ARG_HWCAP flag before accessing the second argument.
>> 
>> The _IFUNC_ARG_HWCAP flag is not reserved on the kernel side.  I think
>> it should be.
>
> the kernel patch added documentation about it
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-April/646891.html
>
> the top two bits of a 64bit AT_HWCAP is guaranteed to be 0,
> right now only the bottom 32bits are used and new bits go
> to AT_HWCAP2 (but later if ilp32 support is dropped from
> the kernel they may use some of the top bits of AT_HWCAP)

Ah, I had only looked at the UAPI header.

| For interoperation with userspace, the kernel guarantees that bits 62
| and 63 of AT_HWCAP will always be returned as 0.

It's not as explicit as I would like (kind of like “reserved, must be
zero“ in the Internet RFCs), but it's better than nothing.

Thanks,
Florian