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

[Andrew Turner]

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

Andrew