[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250708162011.GN1827@brightrain.aerifal.cx>
Date: Tue, 8 Jul 2025 12:20:11 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: aarch64 SME support issues
On Sun, Jul 06, 2025 at 08:20:40PM +0200, Szabolcs Nagy wrote:
> * 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
Based on what you've said below I think that's not a good idea. See
inline responses:
> 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.
The documentation I found for using SME says it's required to use the
hwcap bit to determine availability, not other means.
> 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.
Yes, that's not generally the way musl deals with safety tho.
> 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.
I'm planning to include your patch exposing __getauxval in this
release, which would thereby enable SME support on musl in a way that
would silently break. So it sounds like adding __getauxval and one of
either masking off hwcap, or actually adding working SME support, need
to happen "atomically" in the same release in order not to put broken
configurations into the wild.
> 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.
It sounds like this was a commercial consideration for rapidly pushing
a new feature to be available on existing system versions not actually
prepared to support it safely. The norm should be that new
functionality doesn't necessarily work on older systems and
applications need to be prepared for that.
> 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
Do you have a recommendation/preference beween masking it off or
dropping the __getauxval exposure for now?
I think I'd rather mask it off, since in the (unusual but plausible)
case where a static-only toolchain is built, I think the libgccc
configure test will see the hidden __getauxval and be able to use it
already.
And if we do masking, I think it makes sense to mask off all unknown
bits so this doesn't happen again in the future with the next new
thing, but I'm not sure. Does this sound reasonable? Are there any
cases where *hiding* a hwcap bit could result in malfunction?
> > 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.
Indeed, that doesn't seem like a great idea.
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.
