[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260311175831.GI1827@brightrain.aerifal.cx>
Date: Wed, 11 Mar 2026 13:58:31 -0400
From: Rich Felker <dalias@...c.org>
To: James Y Knight <jyknight@...gle.com>, musl@...ts.openwall.com,
Thorsten Glaser <tg@...bsd.de>
Subject: Re: Question about flexible array
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.
> > > 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.
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.
