[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <558B301B.7050206@landley.net>
Date: Wed, 24 Jun 2015 17:32:59 -0500
From: Rob Landley <rob@...dley.net>
To: Rich Felker <dalias@...c.org>
CC: musl@...ts.openwall.com
Subject: Re: SH sigcontext ABI is broken
On 06/24/2015 04:34 PM, Rich Felker wrote:
> On Wed, Jun 24, 2015 at 03:40:50AM -0500, Rob Landley wrote:
>>> 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.
>>
>> This is the "lost the plot" part. I don't get it. What's the point? I do
>> not understand why you have this as a goal.
>
> I'll try to keep this brief since it's not the point of this thread:
>
> - Ability to test your binaries with qemu-[system-]sh4[eb].
I have a todo item to teach that about sh2.
> - 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.
> - Upgrade path from SH2 to SH4.
It's open source. You can recompile.
> - 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.
>>> 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?
>>> 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
>> 0pf.org'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 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.
