Date: Thu, 14 Feb 2013 08:16:43 +1300 From: Andrew Turner <andrew@fubar.geek.nz> To: Konstantin Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: svn commit: r246706 - head/lib/libc/arm/aeabi Message-ID: <20130214081643.3f6ee664@bender> In-Reply-To: <20130213140006.GP2522@kib.kiev.ua> References: <201302120604.r1C64pEW008741@svn.freebsd.org> <511A5277.8060507@freebsd.org> <20130213222546.315be533@bender> <20130213140006.GP2522@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Feb 2013 16:00:06 +0200 Konstantin Belousov <kostikbel@gmail.com> 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 <nwhitehorn@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130214081643.3f6ee664>