Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 24 Jun 2015 18:26:05 -0500
From: Bobby Bingham <>
To: Rob Landley <>
Subject: Re: SH sigcontext ABI is broken

On Wed, Jun 24, 2015 at 05:32:59PM -0500, Rob Landley wrote:
> On 06/24/2015 04:34 PM, Rich Felker wrote:
> > On Wed, Jun 24, 2015 at 03:40:50AM -0500, Rob Landley wrote:
> > - Ability to test your binaries with qemu-[system-]sh4[eb].
> I have a todo item to teach that about sh2.

With the ability for the SH4 kernel to run SH2 binaries, there'd be no
need to teach qemu-system anything.

> > - Ability to test and debug on a real machine with MMU where crashes
> >   are debuggable and don't bring down the whole system.
> If what you want is a debugging tool, a qemu-sh2 application emulation
> could in theory debug those crashes too.
> > - Avoiding death-by-target-combinatorics (ala uclibc).
> sh2 will not run an sh4 binary. Restricting sh4 to only running sh2
> binaries would cripple the platform. The remaining sliver of use case
> seems to be debugging.

I think this has more to do with the maintenance effort for musl to
support both sh2 and sh4.  Yes, supporting sh2 is already more work than
sh4 due to nommu and different atomics, but the different ucontext_t
layout is just a gratuitous difference.

> > - Upgrade path from SH2 to SH4.
> It's open source. You can recompile.

Surely you're not implying that J2 and J4 are intended to only run open
source software?

> > - Sharing base userspace between low-end SH2 devices and higher-end
> >   SH4-based model.
> It's open source. You can recompile.
> > If you want to discuss this in more detail let's do it somewhere other
> > than in a thread CC'd on several lists it's not terribly relevant to.
> Trimmed the glibc and kernel lists from this reply.
> >>> 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.
> >>
> >> Yes, a separate ABI for sh2 vs sh4 has not, historically speaking, been
> >> a problem.
> > 
> > Separate userspace ABI is not a problem. The problem is the kernel
> > ABI.
> The binary loader is kernel abi. The system call interface is kernel abi.

Yes.  And there's no good reason those shouldn't support SH2/3 binaries
on SH2A/4 kernels.

Rich already has patches for the loader and for the trap number.
Fixing the ucontext_t definition in the kernel should more or less be a
matter of removing an #ifdef.

> >>> 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.
> >>
> >> And historically used entirely different trap numbers for system calls,
> >> although you made a kernel patch for that. And a couple more to the
> >> kernel binary loader...
> > 
> > The trap numbers are something that can be worked around even without
> > my patch; it's just ugly. There's really no workaround for a type
> > varying at runtime, though. (The closest thing to a valid workaround
> > would be wrapped signal handlers, which are really ugly to implement;
> > glibc has considered doing them but so far held off. I don't want to
> > do them.)
> I do not understand your purpose here. I don't see the point of the goal.
> >>> 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.
> >>
> >> Or sh2 vs sh4 could be different compile-time targets with different
> >> libc instances?
> > 
> > They already are (assuming you use FPU on SH4; then one is using the
> > hard-float ABI and the other is using soft-float ABI), but that
> > doesn't help. The problem is the kernel ABI.
> If they're different compile-time targets, how is varying kernel ABI a
> problem?

This is like saying a kernel compiled for a pentium 4 shouldn't be able
to run a pentium 3 usersapce because p4 could use SSE2 for floating
point, and p3 had to use x87 instead.

Different userspace ABIs does necessitate different kernel ABIs.

> >>> 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.
> >>
> >> Old binaries can run under old kernels with old userspace partitions.
> > 
> > Well, not so practical if those old kernels have critical vulns...
> You can rebuild your kernel but not your userspace, and you're running
> Linux?
> There was never any glibc sh2 support. There's no installed base there,
> it was all uclibc, and uclibc is dead, and never had binary
> compatability even between different configs of the same version.
> I also note that Linux support for sh2 went in via commit 9d4436a6fbc8
> in November 2006 which is 9 years ago (2.6.19), so the oldest binaries
> we'd worry about are less than a decade old anyway.
> > But unless someone steps forward and says SH3 ucontext_t ABI is
> > important to existing applications that are deploying new kernels, I
> > think we can just wait to address this issue (with a personality)
> > if/when it ever arises.
> > 
> >>> 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.
> >>
> >> I suspect the issue will just go away too.
> >>
> >> After more patents expire next year, we can add full sh4 compatibility
> >> to j-core. If we want a better userspace api ala x86's x32 or mips
> >> o32/n32/nubi or arm's oabi/eabi, we can do that. (In fact that's one of
> >>'s goals, kawasaki-san is _trying_ to run a standards body. If
> >> you want to wave an abi proposal at him for comment, he is the original
> >> superh architect...)
> > 
> > The SH ABI seems pretty good as-is, especially considering the
> > constraints it's working with. The only additional need for ABI work I
> > see at the moment is getting FDPIC working.
> I thought it was too. I'm confused by the sh2/sh4 unification effort...

I'm confused why you're against it.  Why shouldn't an SH2 userspace
just work on SH2a or SH4, or an SH3 userspace on SH4?

> >> I want musl to support sh2 but I _also_ want it to support coldfire and
> >> h8300 and so on. If musl is the successor to uclibc (which needs to be
> >> put out of its misery), it needs nommu support for several different
> >> architectures. If you insist that every nommu architecture must also run
> >> those nommu binaries on with-mmu sibling architectures, you're going to
> >> be unifying coldfire and m68k next...
> > 
> > If you look at the kernel I'm pretty sure that already works...
> > Coldfire does not seem to be a separate arch/ABI as far as the kernel
> > is concerned.
> I'll take your word for it.
> > Rich
> Rob


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.