[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260311165155.GO3520958@port70.net>
Date: Wed, 11 Mar 2026 17:51:55 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: Rich Felker <dalias@...c.org>
Cc: James Y Knight <jyknight@...gle.com>, musl@...ts.openwall.com,
Thorsten Glaser <tg@...bsd.de>
Subject: Re: Question about flexible array
* 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.
> >
> > 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)
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.
