All of lore.kernel.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: Dave P Martin <Dave.Martin@arm.com>,
	Andrew Murray <Andrew.Murray@arm.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>, nd <nd@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	GNU C Library <libc-alpha@sourceware.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 2/6] arm64: HWCAP: add support for AT_HWCAP2
Date: Fri, 29 Mar 2019 16:44:05 +0000	[thread overview]
Message-ID: <83b59b0f-cee7-92d5-2ed2-5300f92d7329@arm.com> (raw)
In-Reply-To: <20190328112734.GZ3567@e103592.cambridge.arm.com>

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.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-29 16:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-21 12:20 [PATCH v2 0/6] Initial support for CVADP Andrew Murray
2019-02-21 12:20 ` [PATCH v2 1/6] arm64: Handle trapped DC CVADP Andrew Murray
2019-02-21 12:39   ` Mark Rutland
2019-02-21 12:20 ` [PATCH v2 2/6] arm64: HWCAP: add support for AT_HWCAP2 Andrew Murray
2019-02-21 18:45   ` Dave P Martin
2019-02-22 10:35     ` Szabolcs Nagy
2019-03-27 15:02       ` Andrew Murray
2019-03-27 15:24         ` Andrew Murray
2019-03-28 11:27           ` Dave Martin
2019-03-29 16:44             ` Szabolcs Nagy [this message]
2019-03-29 16:57               ` Phil Blundell
2019-04-01  8:14                 ` Andrew Murray
2019-03-27 14:53     ` Andrew Murray
2019-03-29 15:39   ` Dave Martin
2019-02-21 12:20 ` [PATCH v2 3/6] arm64: HWCAP: encapsulate elf_hwcap Andrew Murray
2019-02-21 18:45   ` Dave P Martin
2019-03-27 14:03     ` Andrew Murray
2019-03-28 11:32       ` Dave Martin
2019-02-21 12:20 ` [PATCH v2 4/6] arm64: Expose DC CVADP to userspace Andrew Murray
2019-02-21 12:20 ` [PATCH v2 5/6] arm64: add CVADP support to the cache maintenance helper Andrew Murray
2019-02-21 12:20 ` [PATCH v2 6/6] arm64: Advertise ARM64_HAS_DCPODP cpu feature Andrew Murray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83b59b0f-cee7-92d5-2ed2-5300f92d7329@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=Andrew.Murray@arm.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=nd@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.