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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Szabolcs Nagy-2
On 28/03/2019 11:27, Dave Martin wrote:

> On Wed, Mar 27, 2019 at 03:24:15PM +0000, Andrew Murray wrote:
>> On Wed, Mar 27, 2019 at 03:02:25PM +0000, Andrew Murray wrote:
>>> 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.
>
> Since the main reason for reserving bits [63:32] is ILP32, and it's
> still unclear when (or if) that will be merged, it feels a bit excessive
> to promise that we will never use these bits.
>
> It sounds like glibc has a use for at most one bit in here.
>
> So maybe we can reserve bit 63 (or 32, whatever) and promise that is
> zero, but leave the rest uncommitted for now.
>
> Szabolcs, does that sound sensible?

i think hwcap bit 63 is already reserved by glibc
internally for tls support, it is not clear to me
if that's still relevant (aarch64 post-dates tls
support, so this might be historical cruft that can
be cleaned up), i only see one comment about it:

1288   /* The last entry in hwcap_extra is reserved for the "tls" pseudo-hwcap which
1289      indicates support for TLS.  This pseudo-hwcap is only used by old versions
1290      under which TLS support was optional.  The entry is no longer needed, but
1291      must remain for compatibility.  */
1292   hwcap_extra[63 - _DL_FIRST_EXTRA] = "tls";

https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/ldconfig.c;h=3bc9e618916ebb2fee29ffe3d114525a08390b43;hb=HEAD#l1288

and generic ld.so.cache handling code uses it:

https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-cache.c;h=d8d1e2344e612d98689cf7d7ad965822d0ab6ed1;hb=HEAD#l265

since i don't understand how this tls bit was used
exactly i think it's better to use a different bit
for aarch64 ifunc abi hacks (e.g. 1ULL << 62)

cc += libc-alpha in case somebody knows more about
this bit.
Reply | Threaded
Open this post in threaded view
|

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

Phil Blundell-3
On Fri, 2019-03-29 at 16:44 +0000, Szabolcs Nagy wrote:
> i think hwcap bit 63 is already reserved by glibc
> internally for tls support, it is not clear to me
> if that's still relevant (aarch64 post-dates tls
> support, so this might be historical cruft that can
> be cleaned up), i only see one comment about it:

At the time that bit was invented, it was only set when glibc was built
with TLS support enabled (i.e. USE_TLS defined).  It would cause the
dynamic linker to add "tls" as a hwcap subdirectory in its search path, which I guess was useful in the days when TLS-enabled and non-TLS-enabled versions of the same DSO needed to be able to co-exist.

At some later date, I forget when, TLS became mandatory and the USE_TLS
condition went away.  The comment seems to be saying that it was
thought necessary to keep the pseudo-hwcap bit set so that any DSOs in
a "tls" subdirectory would still be found.  That seems like a debatable proposition even at the time, and even more so today, but I guess it was hard to prove the negative.

Even if aarch64 has always had TLS, in principle there might be some
ancient DSOs lurking in "tls" subdirectories which would no longer be
loaded if you were to stop setting that bit.  I'm sure that would be manageable, but equally it doesn't seem that these bits are so scarce that it's worth going to any effort to scavenge old ones.

> i think it's better to use a different bit
> for aarch64 ifunc abi hacks (e.g. 1ULL << 62)

I agree.

p.


Reply | Threaded
Open this post in threaded view
|

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

Andrew Murray
On Fri, Mar 29, 2019 at 04:57:46PM +0000, Phil Blundell wrote:

> On Fri, 2019-03-29 at 16:44 +0000, Szabolcs Nagy wrote:
> > i think hwcap bit 63 is already reserved by glibc
> > internally for tls support, it is not clear to me
> > if that's still relevant (aarch64 post-dates tls
> > support, so this might be historical cruft that can
> > be cleaned up), i only see one comment about it:
>
> At the time that bit was invented, it was only set when glibc was built
> with TLS support enabled (i.e. USE_TLS defined).  It would cause the
> dynamic linker to add "tls" as a hwcap subdirectory in its search path, which I guess was useful in the days when TLS-enabled and non-TLS-enabled versions of the same DSO needed to be able to co-exist.
>
> At some later date, I forget when, TLS became mandatory and the USE_TLS
> condition went away.  The comment seems to be saying that it was
> thought necessary to keep the pseudo-hwcap bit set so that any DSOs in
> a "tls" subdirectory would still be found.  That seems like a debatable proposition even at the time, and even more so today, but I guess it was hard to prove the negative.
>
> Even if aarch64 has always had TLS, in principle there might be some
> ancient DSOs lurking in "tls" subdirectories which would no longer be
> loaded if you were to stop setting that bit.  I'm sure that would be manageable, but equally it doesn't seem that these bits are so scarce that it's worth going to any effort to scavenge old ones.
>
> > i think it's better to use a different bit
> > for aarch64 ifunc abi hacks (e.g. 1ULL << 62)
>
> I agree.

OK, I'll respin and reserve bit 1ULL << 62.

Thanks,

Andrew Murray

>
> p.
>
>