svn commit: r246706 - head/lib/libc/arm/aeabi

[Konstantin Belousov]

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 at 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 ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20130213/05beb33f/attachment.sig>