From owner-svn-src-head@FreeBSD.ORG Wed Feb 13 19:16:50 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A72CE08; Wed, 13 Feb 2013 19:16:50 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from smtp3.clear.net.nz (smtp3.clear.net.nz [203.97.33.64]) by mx1.freebsd.org (Postfix) with ESMTP id DD468A30; Wed, 13 Feb 2013 19:16:49 +0000 (UTC) Received: from mxin3-orange.clear.net.nz (lb2-srcnat.clear.net.nz [203.97.32.237]) by smtp3.clear.net.nz (CLEAR Net Mail) with ESMTP id <0MI600KIEAVYTE20@smtp3.clear.net.nz>; Thu, 14 Feb 2013 08:16:48 +1300 (NZDT) Received: from 202-0-48-19.paradise.net.nz (HELO bender) ([202.0.48.19]) by smtpin32.paradise.net.nz with ESMTP; Thu, 14 Feb 2013 08:16:47 +1300 Date: Thu, 14 Feb 2013 08:16:43 +1300 From: Andrew Turner Subject: Re: svn commit: r246706 - head/lib/libc/arm/aeabi In-reply-to: <20130213140006.GP2522@kib.kiev.ua> To: Konstantin Belousov Message-id: <20130214081643.3f6ee664@bender> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <201302120604.r1C64pEW008741@svn.freebsd.org> <511A5277.8060507@freebsd.org> <20130213222546.315be533@bender> <20130213140006.GP2522@kib.kiev.ua> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Nathan Whitehorn X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 19:16:50 -0000 On Wed, 13 Feb 2013 16:00:06 +0200 Konstantin Belousov wrote: > On Wed, Feb 13, 2013 at 10:25:46PM +1300, 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 > > Does the ABI change happen for the interfaces exported both by > usermode components and kernel, or only usermode components ? Or, > does the kernel exported ABI supports both OABI and EABI ? The ABI change happens on both interfaces. The kernel only exposes a single ABI. For a kernel built with EABI it will be EABI. I started a compat layer to export OABI on EABI kernels however never finished it. If someone is interested in finishing it I can point them to the code. Andrew