[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150624180301.GT1173@brightrain.aerifal.cx>
Date: Wed, 24 Jun 2015 14:03:01 -0400
From: Rich Felker <dalias@...c.org>
To: Rob Landley <rob@...dley.net>
Cc: musl@...ts.openwall.com, libc-alpha@...rceware.org,
linux-sh@...r.kernel.org
Subject: Re: SH sigcontext ABI is broken
On Wed, Jun 24, 2015 at 02:12:58AM -0500, Rob Landley wrote:
> I've lost the plot here, is what I"m saying.
OK, I'll try to get us back on it then.
To begin with, let's put aside musl, revival of SH, and anything new
and just look at the existing situation.
Right now, SH3 or SH4-nofpu binaries are ABI-incompatible with SH4
kernels. This incompatibility is in a place very few applications are
going to use or care about, but it's essential for musl and it's going
to be essential for glibc once they get around to fixing cancellation.
Likewise, SH2 binaries are incompatible with SH2A kernels and SH4
kernels.
I can't imagine this being intentional. While the original SH2 work
was not intended to produce binaries capable of running on later
models, SH3 and SH4 were treated like a normal MMU-ful Linux arch,
where it should aways be possible to run a binary built for cpu
revision M on an actual cpu revision N, where M<=N.
Since our new SH2 binaries (using ELF, musl, and possibly glibc if the
port is not dropped) are also going to be compatible with running on
later MMU-ful hardware (e.g. J4), I don't want this same issue to be a
point of breakage for them.
The userspace SH2 ABI is nofpu (no float registers for float args), so
there is already a separate userspace ABI for SH2 (and SH3) vs the
usual SH4 ABI with float. That's not a problem. Dynamic linked
binaries have their own separate shared library ecosystem, and for
static linked binaries, there's no userspace ABI boundary left once ld
runs. However kernel-user ABI breakage is a show-stopper. It means
that, even if you had the right ldso and libraries for nofpu SH2
binaries, you couldn't safely run them on SH4 because the kernel would
give you the wrong ucontext_t layout.
If we want the SH-nofpu ABI to use the old nofpu ucontext_t layout,
then the kernel (and qemu-user) is going to need a way to detect
nofpu-ABI binaries and generate the right ucontext_t for them.
If we switch to using the same ucontext_t layout everywhere, the
kernel does not have to be smart, and the kernel ABI looks the same
for all SH variants, but old binaries (if they depend on ucontext_t
layout, which is _rare_ anyway) could break.
My leaning at this point, especially since you say SH3 is irrelevant,
is to use the same ucontext_t layout for them all (with the float reg
space empty for nofpu chips). If any real-world old apps break and
people care about them, we could make a personality that you set
manually for old-nofpu ucontext_t layout. But I suspect the issue will
just go away.
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.
