[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250701213703.GF1827@brightrain.aerifal.cx>
Date: Tue, 1 Jul 2025 17:37:03 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: aarch64 SME support issues
There's a thread going on elsewhere (glibc, kernel folks, etc.) that
I'm CC'd on but that has not been on the musl list so far, about
support for the aarch64 SME extension. I was under the impression that
the way things were done on the ISA side, it should be possible to
support applications that use it as long as the kernel does the right
things, without any consideration for whether libc is new enough to
know about it. (This is a condition I would deem necessary for it to
be a transparent, non-ABI-breaking addition.) However, it seems that
may not be the case. Here is a link to the current tail of the thread
(note that it extends back thru June and May as well):
https://sourceware.org/pipermail/libc-alpha/2025-July/168330.html
At present, we should not have any musl-linked applications attempting
to use SME, since it's mandatory to check the hwcap bits for it, and
we have never defined the corresponding hwcap macro. (However it's
possible that someone is wrongly bypassing libc headers and using the
kernel ones, or defining it themselves, in which case they get to keep
both pieces.)
Anyway, the immediate question I have in mind in preparation for a
release is whether we should do something to future-proof for this
now. Specifically, should we have the aarch64 entry code mask off all
unknown hwcap bits? This would make it so if at some point in the
future we expose a macro for SME, applications don't detect it as
available if they're run with 1.2.6. (Note: this wouldn't help with
1.2.5 or earlier, since that ship has already sailed.)
The downside of this is that it would prevent using any other ISA
features newer than what were available when the libc version shipped.
But if ARM is potentially going to be making future ISA extensions
breaking like this, it might be the safety-correct option.
If OTOH applications that use SME reference a libc-provided symbol
(rather than a libgcc-provided one) to do the ABI magic, failure to
resolve symbols would prevent them from being run unsafely, and
there's not any issue.
I'd welcome input from anyone more familiar with the particulars of
SME than myself.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
