[<prev] [next>] [day] [month] [year] [list]
Message-ID: <33e6a0f0-2c1e-4b34-a823-0d8d43c492dc@dereferenced.org>
Date: Wed, 11 Mar 2026 11:46:57 -0700
From: Ariadne Conill <ariadne@...eferenced.org>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
James Y Knight <jyknight@...gle.com>, Thorsten Glaser <tg@...bsd.de>
Subject: Re: Question about flexible array
Hi,
On 3/11/26 10:58, Rich Felker wrote:
> On Wed, Mar 11, 2026 at 05:51:55PM +0100, Szabolcs Nagy wrote:
>> * Rich Felker <dalias@...c.org> [2026-03-11 12:28:05 -0400]:
>>> On Wed, Mar 11, 2026 at 12:13:44PM -0400, James Y Knight wrote:
>>>> Probably you're thinking of
>>>> https://hachyderm.io/@ariadne@treehouse.systems/115698701219076970
>>>>
>>>> I'd agree. The registers f24 - f31 are supposed to be callee-preserved
>>>> in the ABI, yet there is no designated save location within the
>>>> ucontext_t struct in which to place them. Definitely broken.
>> i don't see why.
>>
>> the only question is if there is enough space
>> in mcontext.gregs for all call preserved state
>> with whatever layout. and i think there is.
>> (but i havent counted)
>>
>> the layout of ucontext passed by the kernel to
>> signal handlers and the *context functions in
>> userspace are already different on other targets
>> (i know this for sure on aarch64, but i don't
>> think that was the first to do this),
>> i.e. passing kernel ucontext to a setcontext
>> function is invalid.
> Why is that invalid? My understanding was that you're supposed to be
> able to jump to interrupted-by-signal contexts like this.
>
> Now if there's room in the structure to flag which type of context it
> is, then that would still work.
It works for most architectures in practice, however glibc has a
different userspace ABI for ucontext on powerpc.
In practice, this hasn't mattered: in 9 years of libucontext existing,
nobody has ever complained of problems with libucontext's ABI not
matching glibc. In fact, I only learned about this recently as the
systemd folks have started using libucontext to accelerate their own
context switching (it is interesting to them because you can opt-out of
signal mask restoration).
>>>> The kernel would save the FP registers into the variable-length
>>>> "__extcontext", but that cannot be done by the userspace context
>>>> functions, because they must operate on a fixed-size ucontext_t
>>>> struct, which has no space allocated for this.
>>>>
>>>> While aarch64 uses a very similar extension mechanism -- and similarly
>>>> places FP registers into said extension space -- it defines the
>>>> mcontext as a fixed size struct with 4K of space on the end for
>>>> extension registers. ISTM that loongarch should be doing the same
>>>> thing, rather than using a VLA (or a GNUC 0-length-array kind of VLA).
>>>> That would be an ABI break, though not a terribly impactful one given
>>>> that ucontext is rarely used.
>>>>
>>>> In the meantime...it seems _good_ to have the TBB code fail to
>>>> compile. Switching to a GNUC 0-length array would just be covering up
>>>> a bug here.
>>> I guess my question is: if it has to be a breaking change, should we
>>> go ahead and do that? Right now anything that would break is
>>> presumably already not-working. If we go ahead and change it, is 4k
>>> appropriate, or should we choose a different size?
>> somebody should try to implement *context correctly
>> i think it should work with current abi (just ugly
>> if we have to store float args in int slots)
> If that's true then maybe no action to correct this is needed.
I don't think it is true in terms of how programmers expect the ucontext
functions to behave (in practice, they tend to just save and restore
almost everything, even if they are not required to do so).
Ariadne
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.
