[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250706182040.GH288056@port70.net>
Date: Sun, 6 Jul 2025 20:20:40 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: aarch64 SME support issues
* Rich Felker <dalias@...c.org> [2025-07-01 17:37:03 -0400]:
> 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.)
fwiw i would not fiddle with hwcap for this release
1. there are ways around that (cpu id registers for features
are now emulated for userspace by linux and hwcap is visible
in auxv etc) so we cant do it cleanly.
2. users of sme za state should rarely longjmp or create threads
so we are worrying about a cornercase we havent seen in practice
yet.
3. i think libgcc does not enable sme for musl due to lack of
__getauxval (not configure detected for bootstrap reasons,
based on target triplet, on for *-linux-gnu) so discussion is
moot until libgcc is updated.
morally the sme runtime should be in libc but it ended up in
libgcc because that's supportable in old glibc without abi
update, there were glibc vs gcc release schedule dependency
delays and testability problems otherwise and because 2. the
abi breakage is unlikely.
but yes currently the libc control over sme is via __getauxval
and hwcap masking if we want it off.
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/aarch64/__aarch64_have_sme.c;hb=HEAD
>
> 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.
for newlib libgcc uses a libc symbol __aarch64_sme_accessible
because there is no __getauxval.
but that's problematic for dynamic linking: the sme runtime
is in shared libgcc like the unwinder so all applications using
libgcc would fail not just the sme ones if the symbol is missing.
>
> 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.
