Re: svn commit: r246706 - head/lib/libc/arm/aeabi
On Tue, 12 Feb 2013 08:32:23 -0600 Nathan Whitehorn nwhiteh...@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 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r246706 - head/lib/libc/arm/aeabi
On 02/13/13 03:25, Andrew Turner wrote: On Tue, 12 Feb 2013 08:32:23 -0600 Nathan Whitehorn nwhiteh...@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 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r246706 - head/lib/libc/arm/aeabi
On Wed, Feb 13, 2013 at 10:25:46PM +1300, Andrew Turner wrote: On Tue, 12 Feb 2013 08:32:23 -0600 Nathan Whitehorn nwhiteh...@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 ? pgpMo1gfimiwF.pgp Description: PGP signature
Re: svn commit: r246706 - head/lib/libc/arm/aeabi
On Wed, 13 Feb 2013 16:00:06 +0200 Konstantin Belousov kostik...@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 nwhiteh...@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 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r246706 - head/lib/libc/arm/aeabi
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
On 02/12/13 00:04, Andrew Turner wrote:
Author: andrew
Date: Tue Feb 12 06:04:51 2013
New Revision: 246706
URL: http://svnweb.freebsd.org/changeset/base/246706
Log:
When clang builds libc it may insert calls to __aeabi_* functions. Normally
this is not a problem as they are resolved by libgcc. The exception is for
the __aeabi_mem* functions. These call back into libc to the appropriate
function. This causes issues for static binaries as we only link against
libc once so there is no way for it to call into libgcc and back.
The fix for this is to include these symbols in libc but keep them hidden
so binaries use the libgcc version.
Modified:
head/lib/libc/arm/aeabi/Makefile.inc
Modified: head/lib/libc/arm/aeabi/Makefile.inc
==
--- head/lib/libc/arm/aeabi/Makefile.inc Tue Feb 12 05:56:00 2013
(r246705)
+++ head/lib/libc/arm/aeabi/Makefile.inc Tue Feb 12 06:04:51 2013
(r246706)
@@ -7,5 +7,24 @@ SRCS+= aeabi_atexit.c \
aeabi_float.c \
aeabi_unwind_cpp.c
+# Add the aeabi_mem* functions. While they live in compiler-rt they call into
+# libc. This causes issues when other parts of libc call these functions.
+# We work around this by including these functions in libc but mark them as
+# hidden so users of libc will not pick up these versions.
+.PATH: ${.CURDIR}/../../contrib/compiler-rt/lib/arm
+
+SRCS+= aeabi_memcmp.S \
+ aeabi_memcpy.S \
+ aeabi_memmove.S \
+ aeabi_memset.S
+
+# Mark the functions as hidden so they are not available outside of libc.
+CFLAGS.aeabi_memcmp.S= -DVISIBILITY_HIDDEN
+CFLAGS.aeabi_memcpy.S= -DVISIBILITY_HIDDEN
+CFLAGS.aeabi_memmove.S= -DVISIBILITY_HIDDEN
+CFLAGS.aeabi_memset.S= -DVISIBILITY_HIDDEN
+CFLAGS+= ${CFLAGS.${.IMPSRC:T}}
+
+
SYM_MAPS+=${.CURDIR}/arm/aeabi/Symbol.map
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
svn commit: r246706 - head/lib/libc/arm/aeabi
Author: andrew
Date: Tue Feb 12 06:04:51 2013
New Revision: 246706
URL: http://svnweb.freebsd.org/changeset/base/246706
Log:
When clang builds libc it may insert calls to __aeabi_* functions. Normally
this is not a problem as they are resolved by libgcc. The exception is for
the __aeabi_mem* functions. These call back into libc to the appropriate
function. This causes issues for static binaries as we only link against
libc once so there is no way for it to call into libgcc and back.
The fix for this is to include these symbols in libc but keep them hidden
so binaries use the libgcc version.
Modified:
head/lib/libc/arm/aeabi/Makefile.inc
Modified: head/lib/libc/arm/aeabi/Makefile.inc
==
--- head/lib/libc/arm/aeabi/Makefile.incTue Feb 12 05:56:00 2013
(r246705)
+++ head/lib/libc/arm/aeabi/Makefile.incTue Feb 12 06:04:51 2013
(r246706)
@@ -7,5 +7,24 @@ SRCS+= aeabi_atexit.c \
aeabi_float.c \
aeabi_unwind_cpp.c
+# Add the aeabi_mem* functions. While they live in compiler-rt they call into
+# libc. This causes issues when other parts of libc call these functions.
+# We work around this by including these functions in libc but mark them as
+# hidden so users of libc will not pick up these versions.
+.PATH: ${.CURDIR}/../../contrib/compiler-rt/lib/arm
+
+SRCS+= aeabi_memcmp.S \
+ aeabi_memcpy.S \
+ aeabi_memmove.S \
+ aeabi_memset.S
+
+# Mark the functions as hidden so they are not available outside of libc.
+CFLAGS.aeabi_memcmp.S= -DVISIBILITY_HIDDEN
+CFLAGS.aeabi_memcpy.S= -DVISIBILITY_HIDDEN
+CFLAGS.aeabi_memmove.S=-DVISIBILITY_HIDDEN
+CFLAGS.aeabi_memset.S= -DVISIBILITY_HIDDEN
+CFLAGS+= ${CFLAGS.${.IMPSRC:T}}
+
+
SYM_MAPS+=${.CURDIR}/arm/aeabi/Symbol.map
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
