[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA2zVHoFxTOWeNkb_rEmXtkZKmauRDP29y_e1BgJMe+wpkr2gw@mail.gmail.com>
Date: Wed, 11 Mar 2026 12:13:44 -0400
From: James Y Knight <jyknight@...gle.com>
To: musl@...ts.openwall.com
Cc: Thorsten Glaser <tg@...bsd.de>
Subject: Re: Question about flexible array
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.
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.
On Wed, Mar 11, 2026 at 12:01 AM Rich Felker <dalias@...c.org> wrote:
>
> On Mon, Aug 11, 2025 at 10:42:29AM -0400, Rich Felker wrote:
> > On Mon, Jun 17, 2024 at 04:29:35AM +0000, Thorsten Glaser wrote:
> > > 樊鹏 dixit:
> > >
> > > >The reason is a difference between gcc and g++:
> > > >
> > > >Flexible array members are not officially part of C++.
> > > >Flexible array members were officially standardized in C99.
> > >
> > > >/usr/include/bits/signal.h:35:23: error: flexible array member 'mcontext_t::__extcontext' not at end of 'struct tbb::detail::r1::coroutine_type'
> > >
> > > No, that’s not the problem here (the compiler allows that).
> > >
> > > The problem is this, in oneTBB itself:
> > >
> > > struct coroutine_type {
> > > coroutine_type() : my_context(), my_stack(), my_stack_size() {}
> > > ucontext_t my_context;
> > > void* my_stack;
> > > std::size_t my_stack_size;
> > > };
> > >
> > > There’s a double problem here. One is the ordering. Changing to…
> > >
> > > struct coroutine_type {
> > > coroutine_type() : my_context(), my_stack(), my_stack_size() {}
> > > void* my_stack;
> > > std::size_t my_stack_size;
> > > ucontext_t my_context;
> > > };
> > >
> > > … would fix that, but I *bet* that the surrounding code allocates
> > > its struct coroutine_type by a fixed size and copies my_context
> > > by sizeof(ucontext_t), which necessarily does not include the FAM.
> > >
> > > I’m not sure if it is even permissible for ucontext_t to contain
> > > a FAM; perhaps instead you need to figure out the exact or a
> > > maximum size and change the declaration (and the ABI, most likely)
> > > to that?
> > >
> > > Otherwise, all that’s left is to forbid userspace the copying of
> > > ucontext_t, which probably won’t fly…
> >
> > You can copy it, but there's no guarantee that the copy will be usable
> > for the same purposes the original was. However in this case I don't
> > think it matters. If they're using the ucontext for synchronous
> > coroutines, the vast majority of it, including all of the optional
> > vector state or whatever, is garbage; only the call-saved part of the
> > register file (equivalent to a jmp_buf) is relevant.
>
> Is this something that needs to be fixed? I don't recall where but I
> think it was raised somewhere else, that there doesn't seem to be
> anywhere to store the call-saved fpu registers when implementing the
> ucontext functions...
>
> 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.
