From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8005 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general,gmane.comp.lib.glibc.alpha,gmane.linux.ports.sh.devel Subject: Re: SH sigcontext ABI is broken Date: Wed, 24 Jun 2015 00:52:24 -0400 Message-ID: <20150624045224.GO1173@brightrain.aerifal.cx> References: <20150619070912.GA15025@brightrain.aerifal.cx> <20150620180644.GY1173@brightrain.aerifal.cx> <558A3124.30701@landley.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1435121572 16228 80.91.229.3 (24 Jun 2015 04:52:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Jun 2015 04:52:52 +0000 (UTC) Cc: musl@lists.openwall.com, libc-alpha@sourceware.org, linux-sh@vger.kernel.org To: Rob Landley Original-X-From: musl-return-8018-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 24 06:52:41 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Z7cfw-0003eT-Cs for gllmg-musl@m.gmane.org; Wed, 24 Jun 2015 06:52:40 +0200 Original-Received: (qmail 28361 invoked by uid 550); 24 Jun 2015 04:52:39 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28343 invoked from network); 24 Jun 2015 04:52:38 -0000 Content-Disposition: inline In-Reply-To: <558A3124.30701@landley.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8005 gmane.comp.lib.glibc.alpha:52611 gmane.linux.ports.sh.devel:46753 Archived-At: On Tue, Jun 23, 2015 at 11:25:08PM -0500, Rob Landley wrote: > On 06/20/2015 01:06 PM, Rich Felker wrote: > > So there's a lot of historical mess and breakage here, but sh3 > > binaries have been running with a stable (albeit wrong, IMO) > > definition of ucontext_t/mcontext_t/sigcontext for around 14 years > > now (as long as they only run on sh3 hardware, not sh4). So I'm a bit > > hesitant to consider this something that could be changed with no path > > for compatibility. > > I'm told SH3 was only on sale for about a year between its introduction > and sh4 coming out, at which point everybody switched. There were > significant sh2 deployments and significant sh4 deployments, but sh3 was > more or less a rounding error. The Wikipedia[citation needed] article > doesn't even break it out separately because there's really nothing to > say: https://en.wikipedia.org/?title=SuperH > > (Again, there's a reason qemu-system-sh4 has a 4 in it. At $DAYJOB their > plan is to eventually jump from sh2 straight to sh4 because sh3 doesn't > matter.) > > sh2a was a retcon, started shipping in 2007, a decade after the > dreamcast. Hitachi had already unloaded superh onto Renesas, which did a > big Not Invented Here on superh and kept trying to come up with their > own processor designs. The H in H8300 also stands for Hitachi, so you > can imagine how well Renesas supported it: > > http://permalink.gmane.org/gmane.linux.ports.sh.devel/7237 > > Seriously, It only became interesting again when the patents expired... It's easy to declare SH3 irrelevant when we're not using it, but if we want SH in general to be a serious platform moving forward, there needs to be proper attention to things like not breaking kernel API/ABI and a concern for consensus among users of the platform. Nominally SH3 support remains in both the kernel and glibc. If it can be established that multiple parties agree that there's really no one left who cares about the old no-FPU sigcontext ABI on SH3, I will be all for dropping it and unifying sigcontext. Perhaps a good starting point would be making SH2 (and SH1 if it's even supported at all) use the SH4(/SH2A)-compatible sigcontext layout. For these, I think it's completely implausible that existing software depends on the layout. Rich