[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150619070912.GA15025@brightrain.aerifal.cx>
Date: Fri, 19 Jun 2015 03:09:12 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com, libc-alpha@...rceware.org,
linux-sh@...r.kernel.org
Cc: rob@...dley.net
Subject: SH sigcontext ABI is broken
Presently the SH version of the sigcontext structure, and thus
mcontext_t/ucontext_t, varies in a way that mismatches and breaks ABI.
On the kernel side, whether it has space for FPU registers (or worse,
uses a completely different SH5 layout) depends on whether the kernel
was built for hardware with or without FPU (or for pre-SH5 vs SH5). On
the userspace side, glibc always uses the pre-SH5 layout, but whether
it has space for FPU registers depends on whether the _userspace_
binary was compile for FPU or no-FPU. This can and does mismatch the
kernel's definition when a no-FPU binary is being run on
hardware/kernel with FPU, and the mismatch is particularly bad because
the uc_sigmask member, which signal handlers can legitimately inspect,
moves around depending on which version of the structure is in use.
I did some research and this issue goes way back, to before the
beginning of the kernel git repository.
I see two possible ways forward. The complex but "compatible" (if
there's even such a thing as "compatible" with this mess) is
introducing new personalities for hardfloat vs softfloat sigcontext
ABIs, and having the kernel generate the proper layout for the
personality in use. The way I would prefer is just getting rid of the
#ifdefs around the fpu registers and always including storage for them
in the sigcontext, regardless of whether the machine has FPU. This
would be an ABI "change" in some sense for no-FPU environments, but
being that the ABI is already broken depending on which kernel you're
running, and nobody seems to have even noticed or cared up til now, I
think it's justified.
The SH5 layout is another matter and it's not clear to me whether SH5
can even run 32-bit binaries or whether it's essentially a completely
different arch -- I've never worked with it.
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.
