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