[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA2zVHoSe7bvurSDpqABzA4U-7-RoQssBS03U4Uwxjz4F=dy=g@mail.gmail.com>
Date: Wed, 11 Mar 2026 13:33:44 -0400
From: James Y Knight <jyknight@...gle.com>
To: Rich Felker <dalias@...c.org>, 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 12:51 PM Szabolcs Nagy <nsz@...t70.net> wrote:
>
> 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.
Ah, ok!
I didn't realize this usage was already broken (at least on some
architectures, if not all). I have never tried to do it myself, nor do
I know of any reason why someone would want to, but it is actually
_documented_ to work, per "man setcontext":
"The context should have been obtained by a call of getcontext(), or
makecontext(3), or received as the third argument to a signal handler
(see the discussion of the SA_SIGINFO flag in sigaction(2))."
If it's been broken for aarch64 for a long time (has it been since
aarch64 was added? Or is this recent breakage?), presumably that would
indicate that there's no real-world usage of setcontext/swapcontext on
a kernel-provided ucontext_t...And if that's the case, it's
_extremely_ unfortunate that these functions were defined to use the
same struct as the one provided to a signal handler in the first place
-- they really ought to be using something a lot closer to (if not
exactly) jmp_buf, instead.
Oh well.
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.
