On Wed, 23 Mar 2016, Tom Rini wrote:
On Wed, Mar 23, 2016 at 06:08:45PM +0100, Albert ARIBAUD wrote:
Hello Tom,
On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini <tr...@konsulko.com> wrote:
On Wed, Mar 23, 2016 at 01:53:35PM +0100, Albert ARIBAUD wrote:
Hello Marek,
On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut <ma...@denx.de> wrote:
This patch decouples U-Boot binary from the toolchain on systems where
private libgcc is available. Instead of pulling in functions provided
by the libgcc from the toolchain, U-Boot will use it's own set of libgcc
functions. These functions are usually imported from Linux kernel, which
also uses it's own libgcc functions instead of the ones provided by the
toolchain.
This patch solves a rather common problem. The toolchain can usually
generate code for many variants of target architecture and often even
different endianness. The libgcc on the other hand is usually compiled
for one particular configuration and the functions provided by it may
or may not be suited for use in U-Boot. This can manifest in two ways,
either the U-Boot fails to compile altogether and linker will complain
or, in the much worse case, the resulting U-Boot will build, but will
misbehave in very subtle and hard to debug ways.
I don't think using private libgcc by default is a good idea.
U-Boot's private libgcc is not a feature of U-Boot, but a fix for some
cases where a target cannot properly link with the libgcc provided by
the (specific release of the) GCC toolchain in use. Using private libgcc
to other cases than these does not fix or improve anything; those
other cases were working and did not require any fix in this respect.
This isn't true, exactly. If using clang for example everyone needs to
enable this code. We're also using -fno-builtin -ffreestanding which
should limit the amount of interference from the toolchain. And we get
that.
You mean clang does not produce self-sustained binaries?
clang does not provide "libgcc", so there's no -lgcc providing all of
the functions that are (today) in:
_ashldi3.S _ashrdi3.S _divsi3.S _lshrdi3.S _modsi3.S _udivsi3.S
_umodsi3.S div0.S _uldivmod.S
which aside from __modsi3 and __umodsi3 are all __aeabi_xxx
There is also _udivmoddi4 pulled from libgcc for 64-bit division since we
switched to 64-bit all around ARM. It comes from clock calculations for
video, e.g. from drivers/video/ipu_common.c for i.MX6.
The problem is most of i.MX6 toolchains (including my own) are built with
"-mfloat-abi=hard -mfpu=vfpv3-d16" or something similar so it fails to link
with the rest of U-Boot that is unconditionally built with "-msoft-float"
for unknown reason.
We should either add 64-bit functions to private libgcc so it is built and
linked properly with whatever ABI are nailed down in arch/arm/config.mk or
somehow allow to specify specific ABI flags in board configuration or
wherever else.
I do use a hack like this
=== Cut ===
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 9af6c37..a96868c 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -16,8 +16,14 @@ endif
LDFLAGS_FINAL += --gc-sections
PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
-fno-common -ffixed-r9
-PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
- $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))
+
+ifeq ($(CONFIG_SYS_HARDFP_VFP_BUILD),y)
+PLATFORM_RELFLAGS += $(call cc-option,-mfloat-abi=hard,$(call
cc-option,-mfpu=vfpv3-d16,))
+else
+PLATFORM_RELFLAGS += $(call cc-option, -msoft-float)
+endif
+
+PLATFORM_RELFLAGS += $(call cc-option,-mshort-load-bytes,$(call
cc-option,-malignment-traps,))
=== Cut ===
but this is not very nice so it won't go in the main tree for sure.
A smarter, more elegant way should be invented so the entire U-Boot could be
built with ABI flags matched those used for toolchain build.
Or _ALL_ libgcc functions should be made U-Boot private so no toolchain
parts are used at all.
---
******************************************************************
* KSI@home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
