[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260311192957.GJ1827@brightrain.aerifal.cx>
Date: Wed, 11 Mar 2026 15:29:57 -0400
From: Rich Felker <dalias@...c.org>
To: Ariadne Conill <ariadne@...eferenced.org>
Cc: 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 11:45:42AM -0700, Ariadne Conill wrote:
>
> Hi,
>
> On 3/11/26 09:51, 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.
> In theory, we only need to save $fs0-$fs7.
>
> We could probably use the space for $t0-$t7 to store $fs0-$fs7, as they are
> not marked as saved/restored in the ABI spec.
>
> However, a problem is most implementations of the *context functions just
> save/restore basically everything, and so programmers expect this behavior.
They can't be expecting anything else to be saved, because it was
already clobbered by the act of making a function call to the function
they'd want to save it.
In theory they could expect restoration of parts of the register file
they manually poked at.
> I'm not sure deviating from expectations is a good idea, even if it is
> technically allowed as most programs using the *context functions are not
> using floating point and thus saving the temp registers seems like a safer
> approach.
Even if they're "not using floating point" the compiler can (and will)
elect to use floating point registers as spill space for non-fp data.
You can't skip saving them if them being call-saved is part of the ABI.
> This is why it has not been a priority for me to investigate as a path to
> supporting hard-float for LoongArch in libucontext.
>
> > > > 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)
> >
> Another problem is that some programs want to inspect the context (we have
> seen this in DRM modules for example with gcompat), so they may be expecting
> floating point data in the place it would normally be.
>
> This is another reason why I haven't bothered making libucontext hard-float
> on LoongArch yet.
>
> In practice, it hasn't really mattered yet anyway.
My leaning would be to fix the structure definition to have space to
store the fp registers in the right place rather than stuffing them
somewhere else, but one way or another it needs to be fixed.
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.
