Date: Wed, 13 Feb 2013 07:48:15 -0600 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Andrew Turner <andrew@fubar.geek.nz> Cc: Andrew Turner <andrew@FreeBSD.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r246706 - head/lib/libc/arm/aeabi Message-ID: <511B999F.5080808@freebsd.org> In-Reply-To: <20130213222546.315be533@bender> References: <201302120604.r1C64pEW008741@svn.freebsd.org> <511A5277.8060507@freebsd.org> <20130213222546.315be533@bender>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/13/13 03:25, 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 > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?511B999F.5080808>