From owner-svn-src-all@FreeBSD.ORG Wed Feb 13 13:48:31 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 40C4FA00; Wed, 13 Feb 2013 13:48:31 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0ED308; Wed, 13 Feb 2013 13:48:30 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0MI500L00UXTEC00@smtpauth1.wiscmail.wisc.edu>; Wed, 13 Feb 2013 07:48:24 -0600 (CST) X-Spam-PmxInfo: Server=avs-1, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.13.133315, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (adsl-76-208-68-53.dsl.mdsnwi.sbcglobal.net [76.208.68.53]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0MI500LB1VOGFT00@smtpauth1.wiscmail.wisc.edu>; Wed, 13 Feb 2013 07:48:22 -0600 (CST) X-Wisc-Sender: whitehorn@wisc.edu Message-id: <511B999F.5080808@freebsd.org> Date: Wed, 13 Feb 2013 07:48:15 -0600 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130112 Thunderbird/17.0.2 To: Andrew Turner Subject: Re: svn commit: r246706 - head/lib/libc/arm/aeabi References: <201302120604.r1C64pEW008741@svn.freebsd.org> <511A5277.8060507@freebsd.org> <20130213222546.315be533@bender> In-reply-to: <20130213222546.315be533@bender> Cc: Andrew Turner , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 13:48:31 -0000 On 02/13/13 03:25, Andrew Turner wrote: > On Tue, 12 Feb 2013 08:32:23 -0600 > Nathan Whitehorn wrote: > >> A related question to these commits: are EABI binaries incompatible >> with systems built for OABI? And vice versa? If so, should we mint a >> new MACHINE_ARCH for ARM EABI (or OABI, I guess)? The usual >> implication of sharing a uname -p string is that systems can run each >> other's binaries -- that being broken is a strong argument for a new >> value. -Nathan > > Yes OABI and EABI are binary incompatible. The plan is to kill off OABI > at some stage in the future when EABI is ready. At some time in the > future I plan on flipping the switch to make EABI the default but keep > OABI around to allow people a chance to update. > > I am relying on ARM being a Tier 2 platform to change the ABI such that > we break backward compatibility without changing uname -p. I have the > start of a compat layer in the EABI project branch however never > finished it. If people are interested in updating this compatibility > layer I can point them at the code. > > The other point is backwards compatibility should only be an issue for > ARMv4 and ARMv5 as these are the only cores we have support for on the > any of the current release branches. ARMv6 and ARMv7 is added to 10 and > there has not been an MFC to any of the stable branches. Because of > this I have even less hesitation to stitch the ABI for > TARGET_ARCH=armv6. > > In summary my plan is: > < 9: No change >> = 10: Switch to EABI and remove or depricate OABI > > Andrew > That all makes sense. Thanks for the explanation! If OABI were staying around indefinitely, I think there would be a point to having a new uname but not if it will be deprecated soon. -Nathan