linux-mips
[Top] [All Lists]

RE: MIPS MSA sigcontext changes in 3.15

To: "Joseph S. Myers" <joseph@codesourcery.com>, "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>, "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>
Subject: RE: MIPS MSA sigcontext changes in 3.15
From: Matthew Fortune <Matthew.Fortune@imgtec.com>
Date: Tue, 17 Jun 2014 16:32:40 +0000
Accept-language: en-GB, en-US
In-reply-to: <Pine.LNX.4.64.1406171539240.23412@digraph.polyomino.org.uk>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.LNX.4.64.1406171447030.23412@digraph.polyomino.org.uk> <Pine.LNX.4.64.1406171539240.23412@digraph.polyomino.org.uk>
Sender: linux-mips-bounce@linux-mips.org
Thread-index: AQHPij1bO0gLDabvHkqdHLfQrYWNBJt1YNYAgAAVWKA=
Thread-topic: MIPS MSA sigcontext changes in 3.15
Joseph S. Myers <joseph@codesourcery.com> writes:
> On Tue, 17 Jun 2014, Joseph S. Myers wrote:
> 
> > signal mask at a particular offset in the ucontext.  As far as I can see,
> > extending sigcontext requires a new sigaction flag that could be used to
> > opt in, for a particular signal handler, to receiving the new-layout
> > ucontext (so new symbol versions of sigaction in glibc could then pass
> > that flag to the kernel, but existing binaries would continue to get
> > old-layout ucontext from the kernel), or else putting the new data at the
> 
> And a new flag would itself be problematic - signal handlers would need
> wrapping with userspace code to convert structure layout when new-version
> sigaction is used on an older kernel.  That suggests putting the new data
> at the end of ucontext is to be preferred (but in any case it would be
> best to revert the incompatible changes until something compatible with
> existing userspace can be produced).

An attempt was made to appropriately version the sigcontext structure to
allow readers to determine whether the MSA part of the context was present
or not but this only helps the sigcontext structure and not necessarily
the impact that has on the overall ucontext. On the face of it then it
does seem better to have the extra context at the end of ucontext as it
does indeed look broken for existing glibc versions.

A brief scan of how other architectures have handled extending ucontext
shows a wide variety of solutions although adding to the end of ucontext
seems to be the underlying theme.

Thanks for finding this.

Regards,
Matthew

<Prev in Thread] Current Thread [Next in Thread>