* [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel
@ 2016-03-20 16:15 Marek Vasut
2016-03-20 16:15 ` [U-Boot] [PATCH 2/5] arm: lib: Drop underscore from private libgcc filenames Marek Vasut
` (4 more replies)
0 siblings, 5 replies; 40+ messages in thread
From: Marek Vasut @ 2016-03-20 16:15 UTC (permalink / raw)
To: u-boot
Import unified.h from Linux kernel 4.4.6 , commit
0d1912303e54ed1b2a371be0bba51c384dd57326 . This header file contains
macros used in libgcc functions in Linux kernel on ARM and will be
needed for the libgcc sync.
Since unified.h defines the W(instr) macro, we must drop this from
the macro from memcpy.S , otherwise this triggers a warning about
symbol redefinition. In order to keep the changes to unified.h to
the minimum, tweak arch/arm/lib/Makefile such that it defines new
CONFIG_THUMB2_KERNEL macro, which is already checked by unified.h,
only if Thumb build is enabled, but the target does not support
Thumb2 . This way we can remove ad-hoc -DMEMSET_NO_THUMB_BUILD and
-DMEMCPY_NO_THUMB_BUILD and we do not change the logic.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
---
arch/arm/include/asm/assembler.h | 1 +
arch/arm/include/asm/unified.h | 140 +++++++++++++++++++++++++++++++++++++++
arch/arm/lib/Makefile | 6 +-
arch/arm/lib/memcpy.S | 6 --
4 files changed, 144 insertions(+), 9 deletions(-)
create mode 100644 arch/arm/include/asm/unified.h
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 11b80fb..ae1e42f 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -15,6 +15,7 @@
*/
#include <config.h>
+#include <asm/unified.h>
/*
* Endian independent macros for shifting bytes within registers.
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
new file mode 100644
index 0000000..a91ae49
--- /dev/null
+++ b/arch/arm/include/asm/unified.h
@@ -0,0 +1,140 @@
+/*
+ * include/asm-arm/unified.h - Unified Assembler Syntax helper macros
+ *
+ * Copyright (C) 2008 ARM Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __ASM_UNIFIED_H
+#define __ASM_UNIFIED_H
+
+#if defined(__ASSEMBLY__) && defined(CONFIG_ARM_ASM_UNIFIED)
+ .syntax unified
+#endif
+
+#ifdef CONFIG_CPU_V7M
+#define AR_CLASS(x...)
+#define M_CLASS(x...) x
+#else
+#define AR_CLASS(x...) x
+#define M_CLASS(x...)
+#endif
+
+#ifdef CONFIG_THUMB2_KERNEL
+
+#if __GNUC__ < 4
+#error Thumb-2 kernel requires gcc >= 4
+#endif
+
+/* The CPSR bit describing the instruction set (Thumb) */
+#define PSR_ISETSTATE PSR_T_BIT
+
+#define ARM(x...)
+#define THUMB(x...) x
+#ifdef __ASSEMBLY__
+#define W(instr) instr.w
+#else
+#define WASM(instr) #instr ".w"
+#endif
+
+#else /* !CONFIG_THUMB2_KERNEL */
+
+/* The CPSR bit describing the instruction set (ARM) */
+#define PSR_ISETSTATE 0
+
+#define ARM(x...) x
+#define THUMB(x...)
+#ifdef __ASSEMBLY__
+#define W(instr) instr
+#else
+#define WASM(instr) #instr
+#endif
+
+#endif /* CONFIG_THUMB2_KERNEL */
+
+#ifndef CONFIG_ARM_ASM_UNIFIED
+
+/*
+ * If the unified assembly syntax isn't used (in ARM mode), these
+ * macros expand to an empty string
+ */
+#ifdef __ASSEMBLY__
+ .macro it, cond
+ .endm
+ .macro itt, cond
+ .endm
+ .macro ite, cond
+ .endm
+ .macro ittt, cond
+ .endm
+ .macro itte, cond
+ .endm
+ .macro itet, cond
+ .endm
+ .macro itee, cond
+ .endm
+ .macro itttt, cond
+ .endm
+ .macro ittte, cond
+ .endm
+ .macro ittet, cond
+ .endm
+ .macro ittee, cond
+ .endm
+ .macro itett, cond
+ .endm
+ .macro itete, cond
+ .endm
+ .macro iteet, cond
+ .endm
+ .macro iteee, cond
+ .endm
+#else /* !__ASSEMBLY__ */
+__asm__(
+" .macro it, cond\n"
+" .endm\n"
+" .macro itt, cond\n"
+" .endm\n"
+" .macro ite, cond\n"
+" .endm\n"
+" .macro ittt, cond\n"
+" .endm\n"
+" .macro itte, cond\n"
+" .endm\n"
+" .macro itet, cond\n"
+" .endm\n"
+" .macro itee, cond\n"
+" .endm\n"
+" .macro itttt, cond\n"
+" .endm\n"
+" .macro ittte, cond\n"
+" .endm\n"
+" .macro ittet, cond\n"
+" .endm\n"
+" .macro ittee, cond\n"
+" .endm\n"
+" .macro itett, cond\n"
+" .endm\n"
+" .macro itete, cond\n"
+" .endm\n"
+" .macro iteet, cond\n"
+" .endm\n"
+" .macro iteee, cond\n"
+" .endm\n");
+#endif /* __ASSEMBLY__ */
+
+#endif /* CONFIG_ARM_ASM_UNIFIED */
+
+#endif /* !__ASM_UNIFIED_H */
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 7a0fb58..a930744 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -80,8 +80,8 @@ CFLAGS_cache-cp15.o := -marm
AFLAGS_REMOVE_memset.o := -mthumb -mthumb-interwork
AFLAGS_REMOVE_memcpy.o := -mthumb -mthumb-interwork
-AFLAGS_memset.o := -DMEMSET_NO_THUMB_BUILD
-AFLAGS_memcpy.o := -DMEMCPY_NO_THUMB_BUILD
-
+else
+AFLAGS_memset.o := -DCONFIG_THUMB2_KERNEL
+AFLAGS_memcpy.o := -DCONFIG_THUMB2_KERNEL
endif
endif
diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 7d9fc0f..00602e9 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -13,12 +13,6 @@
#include <linux/linkage.h>
#include <asm/assembler.h>
-#if defined(CONFIG_SYS_THUMB_BUILD) && !defined(MEMCPY_NO_THUMB_BUILD)
-#define W(instr) instr.w
-#else
-#define W(instr) instr
-#endif
-
#define LDR1W_SHIFT 0
#define STR1W_SHIFT 0
--
2.7.0
^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 2/5] arm: lib: Drop underscore from private libgcc filenames
2016-03-20 16:15 [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel Marek Vasut
@ 2016-03-20 16:15 ` Marek Vasut
2016-04-09 18:34 ` Simon Glass
2016-03-20 16:15 ` [U-Boot] [PATCH 3/5] arm: lib: Sync libgcc shift operations Marek Vasut
` (3 subsequent siblings)
4 siblings, 1 reply; 40+ messages in thread
From: Marek Vasut @ 2016-03-20 16:15 UTC (permalink / raw)
To: u-boot
Drop the underscore from the filenames of files implementing libgcc
routines. There is no functional change. This change is done to make
sync with Linux kernel easier.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
---
arch/arm/lib/Makefile | 6 +++---
arch/arm/lib/{_ashldi3.S => ashldi3.S} | 0
arch/arm/lib/{_ashrdi3.S => ashrdi3.S} | 0
arch/arm/lib/{_divsi3.S => divsi3.S} | 0
arch/arm/lib/{_lshrdi3.S => lshrdi3.S} | 0
arch/arm/lib/{_modsi3.S => modsi3.S} | 0
arch/arm/lib/{_udivsi3.S => udivsi3.S} | 0
arch/arm/lib/{_uldivmod.S => uldivmod.S} | 0
arch/arm/lib/{_umodsi3.S => umodsi3.S} | 0
9 files changed, 3 insertions(+), 3 deletions(-)
rename arch/arm/lib/{_ashldi3.S => ashldi3.S} (100%)
rename arch/arm/lib/{_ashrdi3.S => ashrdi3.S} (100%)
rename arch/arm/lib/{_divsi3.S => divsi3.S} (100%)
rename arch/arm/lib/{_lshrdi3.S => lshrdi3.S} (100%)
rename arch/arm/lib/{_modsi3.S => modsi3.S} (100%)
rename arch/arm/lib/{_udivsi3.S => udivsi3.S} (100%)
rename arch/arm/lib/{_uldivmod.S => uldivmod.S} (100%)
rename arch/arm/lib/{_umodsi3.S => umodsi3.S} (100%)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index a930744..7cfe5ab 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -5,9 +5,9 @@
# SPDX-License-Identifier: GPL-2.0+
#
-lib-$(CONFIG_USE_PRIVATE_LIBGCC) += _ashldi3.o _ashrdi3.o _divsi3.o \
- _lshrdi3.o _modsi3.o _udivsi3.o _umodsi3.o div0.o \
- _uldivmod.o
+lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o divsi3.o \
+ lshrdi3.o modsi3.o udivsi3.o umodsi3.o div0.o \
+ uldivmod.o
ifdef CONFIG_CPU_V7M
obj-y += vectors_m.o crt0.o
diff --git a/arch/arm/lib/_ashldi3.S b/arch/arm/lib/ashldi3.S
similarity index 100%
rename from arch/arm/lib/_ashldi3.S
rename to arch/arm/lib/ashldi3.S
diff --git a/arch/arm/lib/_ashrdi3.S b/arch/arm/lib/ashrdi3.S
similarity index 100%
rename from arch/arm/lib/_ashrdi3.S
rename to arch/arm/lib/ashrdi3.S
diff --git a/arch/arm/lib/_divsi3.S b/arch/arm/lib/divsi3.S
similarity index 100%
rename from arch/arm/lib/_divsi3.S
rename to arch/arm/lib/divsi3.S
diff --git a/arch/arm/lib/_lshrdi3.S b/arch/arm/lib/lshrdi3.S
similarity index 100%
rename from arch/arm/lib/_lshrdi3.S
rename to arch/arm/lib/lshrdi3.S
diff --git a/arch/arm/lib/_modsi3.S b/arch/arm/lib/modsi3.S
similarity index 100%
rename from arch/arm/lib/_modsi3.S
rename to arch/arm/lib/modsi3.S
diff --git a/arch/arm/lib/_udivsi3.S b/arch/arm/lib/udivsi3.S
similarity index 100%
rename from arch/arm/lib/_udivsi3.S
rename to arch/arm/lib/udivsi3.S
diff --git a/arch/arm/lib/_uldivmod.S b/arch/arm/lib/uldivmod.S
similarity index 100%
rename from arch/arm/lib/_uldivmod.S
rename to arch/arm/lib/uldivmod.S
diff --git a/arch/arm/lib/_umodsi3.S b/arch/arm/lib/umodsi3.S
similarity index 100%
rename from arch/arm/lib/_umodsi3.S
rename to arch/arm/lib/umodsi3.S
--
2.7.0
^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 3/5] arm: lib: Sync libgcc shift operations
2016-03-20 16:15 [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel Marek Vasut
2016-03-20 16:15 ` [U-Boot] [PATCH 2/5] arm: lib: Drop underscore from private libgcc filenames Marek Vasut
@ 2016-03-20 16:15 ` Marek Vasut
2016-04-09 18:34 ` Simon Glass
2016-03-20 16:15 ` [U-Boot] [PATCH 4/5] arm: lib: Sync libgcc 32b division/modulo operations Marek Vasut
` (2 subsequent siblings)
4 siblings, 1 reply; 40+ messages in thread
From: Marek Vasut @ 2016-03-20 16:15 UTC (permalink / raw)
To: u-boot
Sync the libgcc shift operations with Linux kernel 4.4.6 , commit
0d1912303e54ed1b2a371be0bba51c384dd57326 . Syncing these three
files is easy, as there is almost no change in them, except the
addition of Thumb support.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
---
arch/arm/lib/ashldi3.S | 12 ++++++++----
arch/arm/lib/ashrdi3.S | 12 ++++++++----
arch/arm/lib/lshrdi3.S | 12 ++++++++----
3 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/arch/arm/lib/ashldi3.S b/arch/arm/lib/ashldi3.S
index 9c34c21..a4f5ebb 100644
--- a/arch/arm/lib/ashldi3.S
+++ b/arch/arm/lib/ashldi3.S
@@ -5,6 +5,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
#ifdef __ARMEB__
#define al r1
@@ -14,15 +15,18 @@
#define ah r1
#endif
-.globl __ashldi3
-__ashldi3:
+ENTRY(__ashldi3)
ENTRY(__aeabi_llsl)
subs r3, r2, #32
rsb ip, r2, #32
movmi ah, ah, lsl r2
movpl ah, al, lsl r3
- orrmi ah, ah, al, lsr ip
+ ARM( orrmi ah, ah, al, lsr ip )
+ THUMB( lsrmi r3, al, ip )
+ THUMB( orrmi ah, ah, r3 )
mov al, al, lsl r2
- mov pc, lr
+ ret lr
+
+ENDPROC(__ashldi3)
ENDPROC(__aeabi_llsl)
diff --git a/arch/arm/lib/ashrdi3.S b/arch/arm/lib/ashrdi3.S
index c74fd64..c6e1ed3 100644
--- a/arch/arm/lib/ashrdi3.S
+++ b/arch/arm/lib/ashrdi3.S
@@ -5,6 +5,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
#ifdef __ARMEB__
#define al r1
@@ -14,15 +15,18 @@
#define ah r1
#endif
-.globl __ashrdi3
-__ashrdi3:
+ENTRY(__ashrdi3)
ENTRY(__aeabi_lasr)
subs r3, r2, #32
rsb ip, r2, #32
movmi al, al, lsr r2
movpl al, ah, asr r3
- orrmi al, al, ah, lsl ip
+ ARM( orrmi al, al, ah, lsl ip )
+ THUMB( lslmi r3, ah, ip )
+ THUMB( orrmi al, al, r3 )
mov ah, ah, asr r2
- mov pc, lr
+ ret lr
+
+ENDPROC(__ashrdi3)
ENDPROC(__aeabi_lasr)
diff --git a/arch/arm/lib/lshrdi3.S b/arch/arm/lib/lshrdi3.S
index 1f9b916..9c51141 100644
--- a/arch/arm/lib/lshrdi3.S
+++ b/arch/arm/lib/lshrdi3.S
@@ -5,6 +5,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
#ifdef __ARMEB__
#define al r1
@@ -14,15 +15,18 @@
#define ah r1
#endif
-.globl __lshrdi3
-__lshrdi3:
+ENTRY(__lshrdi3)
ENTRY(__aeabi_llsr)
subs r3, r2, #32
rsb ip, r2, #32
movmi al, al, lsr r2
movpl al, ah, lsr r3
- orrmi al, al, ah, lsl ip
+ ARM( orrmi al, al, ah, lsl ip )
+ THUMB( lslmi r3, ah, ip )
+ THUMB( orrmi al, al, r3 )
mov ah, ah, lsr r2
- mov pc, lr
+ ret lr
+
+ENDPROC(__lshrdi3)
ENDPROC(__aeabi_llsr)
--
2.7.0
^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 4/5] arm: lib: Sync libgcc 32b division/modulo operations
2016-03-20 16:15 [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel Marek Vasut
2016-03-20 16:15 ` [U-Boot] [PATCH 2/5] arm: lib: Drop underscore from private libgcc filenames Marek Vasut
2016-03-20 16:15 ` [U-Boot] [PATCH 3/5] arm: lib: Sync libgcc shift operations Marek Vasut
@ 2016-03-20 16:15 ` Marek Vasut
2016-04-09 18:34 ` Simon Glass
2016-03-20 16:15 ` [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default Marek Vasut
2016-04-09 18:34 ` [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel Simon Glass
4 siblings, 1 reply; 40+ messages in thread
From: Marek Vasut @ 2016-03-20 16:15 UTC (permalink / raw)
To: u-boot
Sync the libgcc 32bit division and modulo operations with Linux 4.4.6 ,
commit 0d1912303e54ed1b2a371be0bba51c384dd57326 . The functions in these
four files are present in lib1funcs.S in Linux, so replace these files
with lib1funcs.S from Linux.
Since we do not support stack unwinding, instead of importing the whole
asm/unwind.h and all the baggage, this patch defines empty UNWIND() macro
in lib1funcs.S . Moreover, to make all of the functions available, define
CONFIG_AEABI , which is safe, because U-Boot is always compiled with ARM
EABI.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
---
arch/arm/lib/Makefile | 5 +-
arch/arm/lib/divsi3.S | 143 -------------------
arch/arm/lib/lib1funcs.S | 351 +++++++++++++++++++++++++++++++++++++++++++++++
arch/arm/lib/modsi3.S | 99 -------------
arch/arm/lib/udivsi3.S | 95 -------------
arch/arm/lib/umodsi3.S | 90 ------------
6 files changed, 353 insertions(+), 430 deletions(-)
delete mode 100644 arch/arm/lib/divsi3.S
create mode 100644 arch/arm/lib/lib1funcs.S
delete mode 100644 arch/arm/lib/modsi3.S
delete mode 100644 arch/arm/lib/udivsi3.S
delete mode 100644 arch/arm/lib/umodsi3.S
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 7cfe5ab..dce6ff9 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -5,9 +5,8 @@
# SPDX-License-Identifier: GPL-2.0+
#
-lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o divsi3.o \
- lshrdi3.o modsi3.o udivsi3.o umodsi3.o div0.o \
- uldivmod.o
+lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o \
+ lib1funcs.o uldivmod.o div0.o
ifdef CONFIG_CPU_V7M
obj-y += vectors_m.o crt0.o
diff --git a/arch/arm/lib/divsi3.S b/arch/arm/lib/divsi3.S
deleted file mode 100644
index c463c68..0000000
--- a/arch/arm/lib/divsi3.S
+++ /dev/null
@@ -1,143 +0,0 @@
-#include <linux/linkage.h>
-
-.macro ARM_DIV_BODY dividend, divisor, result, curbit
-
-#if __LINUX_ARM_ARCH__ >= 5
-
- clz \curbit, \divisor
- clz \result, \dividend
- sub \result, \curbit, \result
- mov \curbit, #1
- mov \divisor, \divisor, lsl \result
- mov \curbit, \curbit, lsl \result
- mov \result, #0
-
-#else
-
- @ Initially shift the divisor left 3 bits if possible,
- @ set curbit accordingly. This allows for curbit to be located
- @ at the left end of each 4 bit nibbles in the division loop
- @ to save one loop in most cases.
- tst \divisor, #0xe0000000
- moveq \divisor, \divisor, lsl #3
- moveq \curbit, #8
- movne \curbit, #1
-
- @ Unless the divisor is very big, shift it up in multiples of
- @ four bits, since this is the amount of unwinding in the main
- @ division loop. Continue shifting until the divisor is
- @ larger than the dividend.
-1: cmp \divisor, #0x10000000
- cmplo \divisor, \dividend
- movlo \divisor, \divisor, lsl #4
- movlo \curbit, \curbit, lsl #4
- blo 1b
-
- @ For very big divisors, we must shift it a bit at a time, or
- @ we will be in danger of overflowing.
-1: cmp \divisor, #0x80000000
- cmplo \divisor, \dividend
- movlo \divisor, \divisor, lsl #1
- movlo \curbit, \curbit, lsl #1
- blo 1b
-
- mov \result, #0
-
-#endif
-
- @ Division loop
-1: cmp \dividend, \divisor
- subhs \dividend, \dividend, \divisor
- orrhs \result, \result, \curbit
- cmp \dividend, \divisor, lsr #1
- subhs \dividend, \dividend, \divisor, lsr #1
- orrhs \result, \result, \curbit, lsr #1
- cmp \dividend, \divisor, lsr #2
- subhs \dividend, \dividend, \divisor, lsr #2
- orrhs \result, \result, \curbit, lsr #2
- cmp \dividend, \divisor, lsr #3
- subhs \dividend, \dividend, \divisor, lsr #3
- orrhs \result, \result, \curbit, lsr #3
- cmp \dividend, #0 @ Early termination?
- movnes \curbit, \curbit, lsr #4 @ No, any more bits to do?
- movne \divisor, \divisor, lsr #4
- bne 1b
-
-.endm
-
-.macro ARM_DIV2_ORDER divisor, order
-
-#if __LINUX_ARM_ARCH__ >= 5
-
- clz \order, \divisor
- rsb \order, \order, #31
-
-#else
-
- cmp \divisor, #(1 << 16)
- movhs \divisor, \divisor, lsr #16
- movhs \order, #16
- movlo \order, #0
-
- cmp \divisor, #(1 << 8)
- movhs \divisor, \divisor, lsr #8
- addhs \order, \order, #8
-
- cmp \divisor, #(1 << 4)
- movhs \divisor, \divisor, lsr #4
- addhs \order, \order, #4
-
- cmp \divisor, #(1 << 2)
- addhi \order, \order, #3
- addls \order, \order, \divisor, lsr #1
-
-#endif
-
-.endm
-
- .align 5
-.globl __divsi3
-__divsi3:
-ENTRY(__aeabi_idiv)
- cmp r1, #0
- eor ip, r0, r1 @ save the sign of the result.
- beq Ldiv0
- rsbmi r1, r1, #0 @ loops below use unsigned.
- subs r2, r1, #1 @ division by 1 or -1 ?
- beq 10f
- movs r3, r0
- rsbmi r3, r0, #0 @ positive dividend value
- cmp r3, r1
- bls 11f
- tst r1, r2 @ divisor is power of 2 ?
- beq 12f
-
- ARM_DIV_BODY r3, r1, r0, r2
-
- cmp ip, #0
- rsbmi r0, r0, #0
- mov pc, lr
-
-10: teq ip, r0 @ same sign ?
- rsbmi r0, r0, #0
- mov pc, lr
-
-11: movlo r0, #0
- moveq r0, ip, asr #31
- orreq r0, r0, #1
- mov pc, lr
-
-12: ARM_DIV2_ORDER r1, r2
-
- cmp ip, #0
- mov r0, r3, lsr r2
- rsbmi r0, r0, #0
- mov pc, lr
-
-Ldiv0:
-
- str lr, [sp, #-4]!
- bl __div0
- mov r0, #0 @ About as wrong as it could be.
- ldr pc, [sp], #4
-ENDPROC(__aeabi_idiv)
diff --git a/arch/arm/lib/lib1funcs.S b/arch/arm/lib/lib1funcs.S
new file mode 100644
index 0000000..5871dbe
--- /dev/null
+++ b/arch/arm/lib/lib1funcs.S
@@ -0,0 +1,351 @@
+/*
+ * linux/arch/arm/lib/lib1funcs.S: Optimized ARM division routines
+ *
+ * Author: Nicolas Pitre <nico@fluxnic.net>
+ * - contributed to gcc-3.4 on Sep 30, 2003
+ * - adapted for the Linux kernel on Oct 2, 2003
+ */
+
+/* Copyright 1995, 1996, 1998, 1999, 2000, 2003 Free Software Foundation, Inc.
+
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+
+/*
+ * U-Boot compatibility bit, define empty UNWIND() macro as, since we
+ * do not support stack unwinding and define CONFIG_AEABI to make all
+ * of the functions available without diverging from Linux code.
+ */
+#ifdef __UBOOT__
+#define UNWIND(x...)
+#define CONFIG_AEABI
+#endif
+
+.macro ARM_DIV_BODY dividend, divisor, result, curbit
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+ clz \curbit, \divisor
+ clz \result, \dividend
+ sub \result, \curbit, \result
+ mov \curbit, #1
+ mov \divisor, \divisor, lsl \result
+ mov \curbit, \curbit, lsl \result
+ mov \result, #0
+
+#else
+
+ @ Initially shift the divisor left 3 bits if possible,
+ @ set curbit accordingly. This allows for curbit to be located
+ @ at the left end of each 4 bit nibbles in the division loop
+ @ to save one loop in most cases.
+ tst \divisor, #0xe0000000
+ moveq \divisor, \divisor, lsl #3
+ moveq \curbit, #8
+ movne \curbit, #1
+
+ @ Unless the divisor is very big, shift it up in multiples of
+ @ four bits, since this is the amount of unwinding in the main
+ @ division loop. Continue shifting until the divisor is
+ @ larger than the dividend.
+1: cmp \divisor, #0x10000000
+ cmplo \divisor, \dividend
+ movlo \divisor, \divisor, lsl #4
+ movlo \curbit, \curbit, lsl #4
+ blo 1b
+
+ @ For very big divisors, we must shift it a bit at a time, or
+ @ we will be in danger of overflowing.
+1: cmp \divisor, #0x80000000
+ cmplo \divisor, \dividend
+ movlo \divisor, \divisor, lsl #1
+ movlo \curbit, \curbit, lsl #1
+ blo 1b
+
+ mov \result, #0
+
+#endif
+
+ @ Division loop
+1: cmp \dividend, \divisor
+ subhs \dividend, \dividend, \divisor
+ orrhs \result, \result, \curbit
+ cmp \dividend, \divisor, lsr #1
+ subhs \dividend, \dividend, \divisor, lsr #1
+ orrhs \result, \result, \curbit, lsr #1
+ cmp \dividend, \divisor, lsr #2
+ subhs \dividend, \dividend, \divisor, lsr #2
+ orrhs \result, \result, \curbit, lsr #2
+ cmp \dividend, \divisor, lsr #3
+ subhs \dividend, \dividend, \divisor, lsr #3
+ orrhs \result, \result, \curbit, lsr #3
+ cmp \dividend, #0 @ Early termination?
+ movnes \curbit, \curbit, lsr #4 @ No, any more bits to do?
+ movne \divisor, \divisor, lsr #4
+ bne 1b
+
+.endm
+
+
+.macro ARM_DIV2_ORDER divisor, order
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+ clz \order, \divisor
+ rsb \order, \order, #31
+
+#else
+
+ cmp \divisor, #(1 << 16)
+ movhs \divisor, \divisor, lsr #16
+ movhs \order, #16
+ movlo \order, #0
+
+ cmp \divisor, #(1 << 8)
+ movhs \divisor, \divisor, lsr #8
+ addhs \order, \order, #8
+
+ cmp \divisor, #(1 << 4)
+ movhs \divisor, \divisor, lsr #4
+ addhs \order, \order, #4
+
+ cmp \divisor, #(1 << 2)
+ addhi \order, \order, #3
+ addls \order, \order, \divisor, lsr #1
+
+#endif
+
+.endm
+
+
+.macro ARM_MOD_BODY dividend, divisor, order, spare
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+ clz \order, \divisor
+ clz \spare, \dividend
+ sub \order, \order, \spare
+ mov \divisor, \divisor, lsl \order
+
+#else
+
+ mov \order, #0
+
+ @ Unless the divisor is very big, shift it up in multiples of
+ @ four bits, since this is the amount of unwinding in the main
+ @ division loop. Continue shifting until the divisor is
+ @ larger than the dividend.
+1: cmp \divisor, #0x10000000
+ cmplo \divisor, \dividend
+ movlo \divisor, \divisor, lsl #4
+ addlo \order, \order, #4
+ blo 1b
+
+ @ For very big divisors, we must shift it a bit at a time, or
+ @ we will be in danger of overflowing.
+1: cmp \divisor, #0x80000000
+ cmplo \divisor, \dividend
+ movlo \divisor, \divisor, lsl #1
+ addlo \order, \order, #1
+ blo 1b
+
+#endif
+
+ @ Perform all needed subtractions to keep only the reminder.
+ @ Do comparisons in batch of 4 first.
+ subs \order, \order, #3 @ yes, 3 is intended here
+ blt 2f
+
+1: cmp \dividend, \divisor
+ subhs \dividend, \dividend, \divisor
+ cmp \dividend, \divisor, lsr #1
+ subhs \dividend, \dividend, \divisor, lsr #1
+ cmp \dividend, \divisor, lsr #2
+ subhs \dividend, \dividend, \divisor, lsr #2
+ cmp \dividend, \divisor, lsr #3
+ subhs \dividend, \dividend, \divisor, lsr #3
+ cmp \dividend, #1
+ mov \divisor, \divisor, lsr #4
+ subges \order, \order, #4
+ bge 1b
+
+ tst \order, #3
+ teqne \dividend, #0
+ beq 5f
+
+ @ Either 1, 2 or 3 comparison/subtractions are left.
+2: cmn \order, #2
+ blt 4f
+ beq 3f
+ cmp \dividend, \divisor
+ subhs \dividend, \dividend, \divisor
+ mov \divisor, \divisor, lsr #1
+3: cmp \dividend, \divisor
+ subhs \dividend, \dividend, \divisor
+ mov \divisor, \divisor, lsr #1
+4: cmp \dividend, \divisor
+ subhs \dividend, \dividend, \divisor
+5:
+.endm
+
+
+ENTRY(__udivsi3)
+ENTRY(__aeabi_uidiv)
+UNWIND(.fnstart)
+
+ subs r2, r1, #1
+ reteq lr
+ bcc Ldiv0
+ cmp r0, r1
+ bls 11f
+ tst r1, r2
+ beq 12f
+
+ ARM_DIV_BODY r0, r1, r2, r3
+
+ mov r0, r2
+ ret lr
+
+11: moveq r0, #1
+ movne r0, #0
+ ret lr
+
+12: ARM_DIV2_ORDER r1, r2
+
+ mov r0, r0, lsr r2
+ ret lr
+
+UNWIND(.fnend)
+ENDPROC(__udivsi3)
+ENDPROC(__aeabi_uidiv)
+
+ENTRY(__umodsi3)
+UNWIND(.fnstart)
+
+ subs r2, r1, #1 @ compare divisor with 1
+ bcc Ldiv0
+ cmpne r0, r1 @ compare dividend with divisor
+ moveq r0, #0
+ tsthi r1, r2 @ see if divisor is power of 2
+ andeq r0, r0, r2
+ retls lr
+
+ ARM_MOD_BODY r0, r1, r2, r3
+
+ ret lr
+
+UNWIND(.fnend)
+ENDPROC(__umodsi3)
+
+ENTRY(__divsi3)
+ENTRY(__aeabi_idiv)
+UNWIND(.fnstart)
+
+ cmp r1, #0
+ eor ip, r0, r1 @ save the sign of the result.
+ beq Ldiv0
+ rsbmi r1, r1, #0 @ loops below use unsigned.
+ subs r2, r1, #1 @ division by 1 or -1 ?
+ beq 10f
+ movs r3, r0
+ rsbmi r3, r0, #0 @ positive dividend value
+ cmp r3, r1
+ bls 11f
+ tst r1, r2 @ divisor is power of 2 ?
+ beq 12f
+
+ ARM_DIV_BODY r3, r1, r0, r2
+
+ cmp ip, #0
+ rsbmi r0, r0, #0
+ ret lr
+
+10: teq ip, r0 @ same sign ?
+ rsbmi r0, r0, #0
+ ret lr
+
+11: movlo r0, #0
+ moveq r0, ip, asr #31
+ orreq r0, r0, #1
+ ret lr
+
+12: ARM_DIV2_ORDER r1, r2
+
+ cmp ip, #0
+ mov r0, r3, lsr r2
+ rsbmi r0, r0, #0
+ ret lr
+
+UNWIND(.fnend)
+ENDPROC(__divsi3)
+ENDPROC(__aeabi_idiv)
+
+ENTRY(__modsi3)
+UNWIND(.fnstart)
+
+ cmp r1, #0
+ beq Ldiv0
+ rsbmi r1, r1, #0 @ loops below use unsigned.
+ movs ip, r0 @ preserve sign of dividend
+ rsbmi r0, r0, #0 @ if negative make positive
+ subs r2, r1, #1 @ compare divisor with 1
+ cmpne r0, r1 @ compare dividend with divisor
+ moveq r0, #0
+ tsthi r1, r2 @ see if divisor is power of 2
+ andeq r0, r0, r2
+ bls 10f
+
+ ARM_MOD_BODY r0, r1, r2, r3
+
+10: cmp ip, #0
+ rsbmi r0, r0, #0
+ ret lr
+
+UNWIND(.fnend)
+ENDPROC(__modsi3)
+
+#ifdef CONFIG_AEABI
+
+ENTRY(__aeabi_uidivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr} )
+
+ stmfd sp!, {r0, r1, ip, lr}
+ bl __aeabi_uidiv
+ ldmfd sp!, {r1, r2, ip, lr}
+ mul r3, r0, r2
+ sub r1, r1, r3
+ ret lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_uidivmod)
+
+ENTRY(__aeabi_idivmod)
+UNWIND(.fnstart)
+UNWIND(.save {r0, r1, ip, lr} )
+ stmfd sp!, {r0, r1, ip, lr}
+ bl __aeabi_idiv
+ ldmfd sp!, {r1, r2, ip, lr}
+ mul r3, r0, r2
+ sub r1, r1, r3
+ ret lr
+
+UNWIND(.fnend)
+ENDPROC(__aeabi_idivmod)
+
+#endif
+
+Ldiv0:
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+ str lr, [sp, #-8]!
+ bl __div0
+ mov r0, #0 @ About as wrong as it could be.
+ ldr pc, [sp], #8
+UNWIND(.fnend)
+ENDPROC(Ldiv0)
diff --git a/arch/arm/lib/modsi3.S b/arch/arm/lib/modsi3.S
deleted file mode 100644
index c5e1c22..0000000
--- a/arch/arm/lib/modsi3.S
+++ /dev/null
@@ -1,99 +0,0 @@
-#include <linux/linkage.h>
-
-.macro ARM_MOD_BODY dividend, divisor, order, spare
-
-#if __LINUX_ARM_ARCH__ >= 5
-
- clz \order, \divisor
- clz \spare, \dividend
- sub \order, \order, \spare
- mov \divisor, \divisor, lsl \order
-
-#else
-
- mov \order, #0
-
- @ Unless the divisor is very big, shift it up in multiples of
- @ four bits, since this is the amount of unwinding in the main
- @ division loop. Continue shifting until the divisor is
- @ larger than the dividend.
-1: cmp \divisor, #0x10000000
- cmplo \divisor, \dividend
- movlo \divisor, \divisor, lsl #4
- addlo \order, \order, #4
- blo 1b
-
- @ For very big divisors, we must shift it a bit at a time, or
- @ we will be in danger of overflowing.
-1: cmp \divisor, #0x80000000
- cmplo \divisor, \dividend
- movlo \divisor, \divisor, lsl #1
- addlo \order, \order, #1
- blo 1b
-
-#endif
-
- @ Perform all needed substractions to keep only the reminder.
- @ Do comparisons in batch of 4 first.
- subs \order, \order, #3 @ yes, 3 is intended here
- blt 2f
-
-1: cmp \dividend, \divisor
- subhs \dividend, \dividend, \divisor
- cmp \dividend, \divisor, lsr #1
- subhs \dividend, \dividend, \divisor, lsr #1
- cmp \dividend, \divisor, lsr #2
- subhs \dividend, \dividend, \divisor, lsr #2
- cmp \dividend, \divisor, lsr #3
- subhs \dividend, \dividend, \divisor, lsr #3
- cmp \dividend, #1
- mov \divisor, \divisor, lsr #4
- subges \order, \order, #4
- bge 1b
-
- tst \order, #3
- teqne \dividend, #0
- beq 5f
-
- @ Either 1, 2 or 3 comparison/substractions are left.
-2: cmn \order, #2
- blt 4f
- beq 3f
- cmp \dividend, \divisor
- subhs \dividend, \dividend, \divisor
- mov \divisor, \divisor, lsr #1
-3: cmp \dividend, \divisor
- subhs \dividend, \dividend, \divisor
- mov \divisor, \divisor, lsr #1
-4: cmp \dividend, \divisor
- subhs \dividend, \dividend, \divisor
-5:
-.endm
-
- .align 5
-ENTRY(__modsi3)
- cmp r1, #0
- beq Ldiv0
- rsbmi r1, r1, #0 @ loops below use unsigned.
- movs ip, r0 @ preserve sign of dividend
- rsbmi r0, r0, #0 @ if negative make positive
- subs r2, r1, #1 @ compare divisor with 1
- cmpne r0, r1 @ compare dividend with divisor
- moveq r0, #0
- tsthi r1, r2 @ see if divisor is power of 2
- andeq r0, r0, r2
- bls 10f
-
- ARM_MOD_BODY r0, r1, r2, r3
-
-10: cmp ip, #0
- rsbmi r0, r0, #0
- mov pc, lr
-ENDPROC(__modsi3)
-
-Ldiv0:
-
- str lr, [sp, #-4]!
- bl __div0
- mov r0, #0 @ About as wrong as it could be.
- ldr pc, [sp], #4
diff --git a/arch/arm/lib/udivsi3.S b/arch/arm/lib/udivsi3.S
deleted file mode 100644
index 3b653be..0000000
--- a/arch/arm/lib/udivsi3.S
+++ /dev/null
@@ -1,95 +0,0 @@
-#include <linux/linkage.h>
-
-/* # 1 "libgcc1.S" */
-@ libgcc1 routines for ARM cpu.
-@ Division routines, written by Richard Earnshaw, (rearnsha at armltd.co.uk)
-dividend .req r0
-divisor .req r1
-result .req r2
-curbit .req r3
-/* ip .req r12 */
-/* sp .req r13 */
-/* lr .req r14 */
-/* pc .req r15 */
- .text
- .globl __udivsi3
- .type __udivsi3 ,function
- .globl __aeabi_uidiv
- .type __aeabi_uidiv ,function
- .align 0
- __udivsi3:
- __aeabi_uidiv:
- cmp divisor, #0
- beq Ldiv0
- mov curbit, #1
- mov result, #0
- cmp dividend, divisor
- bcc Lgot_result
-Loop1:
- @ Unless the divisor is very big, shift it up in multiples of
- @ four bits, since this is the amount of unwinding in the main
- @ division loop. Continue shifting until the divisor is
- @ larger than the dividend.
- cmp divisor, #0x10000000
- cmpcc divisor, dividend
- movcc divisor, divisor, lsl #4
- movcc curbit, curbit, lsl #4
- bcc Loop1
-Lbignum:
- @ For very big divisors, we must shift it a bit at a time, or
- @ we will be in danger of overflowing.
- cmp divisor, #0x80000000
- cmpcc divisor, dividend
- movcc divisor, divisor, lsl #1
- movcc curbit, curbit, lsl #1
- bcc Lbignum
-Loop3:
- @ Test for possible subtractions, and note which bits
- @ are done in the result. On the final pass, this may subtract
- @ too much from the dividend, but the result will be ok, since the
- @ "bit" will have been shifted out at the bottom.
- cmp dividend, divisor
- subcs dividend, dividend, divisor
- orrcs result, result, curbit
- cmp dividend, divisor, lsr #1
- subcs dividend, dividend, divisor, lsr #1
- orrcs result, result, curbit, lsr #1
- cmp dividend, divisor, lsr #2
- subcs dividend, dividend, divisor, lsr #2
- orrcs result, result, curbit, lsr #2
- cmp dividend, divisor, lsr #3
- subcs dividend, dividend, divisor, lsr #3
- orrcs result, result, curbit, lsr #3
- cmp dividend, #0 @ Early termination?
- movnes curbit, curbit, lsr #4 @ No, any more bits to do?
- movne divisor, divisor, lsr #4
- bne Loop3
-Lgot_result:
- mov r0, result
- mov pc, lr
-Ldiv0:
- str lr, [sp, #-4]!
- bl __div0 (PLT)
- mov r0, #0 @ about as wrong as it could be
- ldmia sp!, {pc}
- .size __udivsi3 , . - __udivsi3
-
-ENTRY(__aeabi_uidivmod)
-
- stmfd sp!, {r0, r1, ip, lr}
- bl __aeabi_uidiv
- ldmfd sp!, {r1, r2, ip, lr}
- mul r3, r0, r2
- sub r1, r1, r3
- mov pc, lr
-ENDPROC(__aeabi_uidivmod)
-
-ENTRY(__aeabi_idivmod)
-
- stmfd sp!, {r0, r1, ip, lr}
- bl __aeabi_idiv
- ldmfd sp!, {r1, r2, ip, lr}
- mul r3, r0, r2
- sub r1, r1, r3
- mov pc, lr
-ENDPROC(__aeabi_idivmod)
diff --git a/arch/arm/lib/umodsi3.S b/arch/arm/lib/umodsi3.S
deleted file mode 100644
index b166737..0000000
--- a/arch/arm/lib/umodsi3.S
+++ /dev/null
@@ -1,90 +0,0 @@
-#include <linux/linkage.h>
-
-/* # 1 "libgcc1.S" */
-@ libgcc1 routines for ARM cpu.
-@ Division routines, written by Richard Earnshaw, (rearnsha at armltd.co.uk)
-/* # 145 "libgcc1.S" */
-dividend .req r0
-divisor .req r1
-overdone .req r2
-curbit .req r3
-/* ip .req r12 */
-/* sp .req r13 */
-/* lr .req r14 */
-/* pc .req r15 */
- .text
- .type __umodsi3 ,function
- .align 0
- ENTRY(__umodsi3)
- cmp divisor, #0
- beq Ldiv0
- mov curbit, #1
- cmp dividend, divisor
- movcc pc, lr
-Loop1:
- @ Unless the divisor is very big, shift it up in multiples of
- @ four bits, since this is the amount of unwinding in the main
- @ division loop. Continue shifting until the divisor is
- @ larger than the dividend.
- cmp divisor, #0x10000000
- cmpcc divisor, dividend
- movcc divisor, divisor, lsl #4
- movcc curbit, curbit, lsl #4
- bcc Loop1
-Lbignum:
- @ For very big divisors, we must shift it a bit at a time, or
- @ we will be in danger of overflowing.
- cmp divisor, #0x80000000
- cmpcc divisor, dividend
- movcc divisor, divisor, lsl #1
- movcc curbit, curbit, lsl #1
- bcc Lbignum
-Loop3:
- @ Test for possible subtractions. On the final pass, this may
- @ subtract too much from the dividend, so keep track of which
- @ subtractions are done, we can fix them up afterwards...
- mov overdone, #0
- cmp dividend, divisor
- subcs dividend, dividend, divisor
- cmp dividend, divisor, lsr #1
- subcs dividend, dividend, divisor, lsr #1
- orrcs overdone, overdone, curbit, ror #1
- cmp dividend, divisor, lsr #2
- subcs dividend, dividend, divisor, lsr #2
- orrcs overdone, overdone, curbit, ror #2
- cmp dividend, divisor, lsr #3
- subcs dividend, dividend, divisor, lsr #3
- orrcs overdone, overdone, curbit, ror #3
- mov ip, curbit
- cmp dividend, #0 @ Early termination?
- movnes curbit, curbit, lsr #4 @ No, any more bits to do?
- movne divisor, divisor, lsr #4
- bne Loop3
- @ Any subtractions that we should not have done will be recorded in
- @ the top three bits of "overdone". Exactly which were not needed
- @ are governed by the position of the bit, stored in ip.
- @ If we terminated early, because dividend became zero,
- @ then none of the below will match, since the bit in ip will not be
- @ in the bottom nibble.
- ands overdone, overdone, #0xe0000000
- moveq pc, lr @ No fixups needed
- tst overdone, ip, ror #3
- addne dividend, dividend, divisor, lsr #3
- tst overdone, ip, ror #2
- addne dividend, dividend, divisor, lsr #2
- tst overdone, ip, ror #1
- addne dividend, dividend, divisor, lsr #1
- mov pc, lr
-Ldiv0:
- str lr, [sp, #-4]!
- bl __div0 (PLT)
- mov r0, #0 @ about as wrong as it could be
- ldmia sp!, {pc}
- .size __umodsi3 , . - __umodsi3
-/* # 320 "libgcc1.S" */
-/* # 421 "libgcc1.S" */
-/* # 433 "libgcc1.S" */
-/* # 456 "libgcc1.S" */
-/* # 500 "libgcc1.S" */
-/* # 580 "libgcc1.S" */
-ENDPROC(__umodsi3)
--
2.7.0
^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-20 16:15 [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel Marek Vasut
` (2 preceding siblings ...)
2016-03-20 16:15 ` [U-Boot] [PATCH 4/5] arm: lib: Sync libgcc 32b division/modulo operations Marek Vasut
@ 2016-03-20 16:15 ` Marek Vasut
2016-03-23 12:53 ` Albert ARIBAUD
2016-04-09 18:34 ` [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel Simon Glass
4 siblings, 1 reply; 40+ messages in thread
From: Marek Vasut @ 2016-03-20 16:15 UTC (permalink / raw)
To: u-boot
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.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
---
lib/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/Kconfig b/lib/Kconfig
index 7a45336..2b911bc 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -14,6 +14,7 @@ config HAVE_PRIVATE_LIBGCC
config USE_PRIVATE_LIBGCC
bool "Use private libgcc"
depends on HAVE_PRIVATE_LIBGCC
+ default y if HAVE_PRIVATE_LIBGCC
help
This option allows you to use the built-in libgcc implementation
of U-Boot instead of the one privided by the compiler.
--
2.7.0
^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-20 16:15 ` [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default Marek Vasut
@ 2016-03-23 12:53 ` Albert ARIBAUD
2016-03-23 13:22 ` Tom Rini
0 siblings, 1 reply; 40+ messages in thread
From: Albert ARIBAUD @ 2016-03-23 12:53 UTC (permalink / raw)
To: u-boot
Hello Marek,
On Sun, 20 Mar 2016 17:15:34 +0100, Marek Vasut <marex@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.
Also, libgcc is not a standalone project that can be frozen, forked or
improved freely; it is an internal component of the GCC toolchain. No
standard defines what libgcc is or should be, and we have no control
over the 'contract' between GCC-emitted code and libgcc. The GCC
project may decide to change that contract at any time, and produce a
new toolchain and a new libgcc. Using our private libgcc by default
will cause all targets to break for no good reason. We've already been
bitten by internal GCC changes on which we were dependent; adding more
such dependency is not the way to go IMO.
If we truly fear that GCC is *generally* unable to properly build our
targets due to its libgcc, then we should not only "snapshot and fix"
libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
sure we keep a consistent copy of it. I don't think that would be a
viable move.
And if we don't believe that GCC is generally unable to properly build
U-Boot, then we should always use it as provided unless it is provably
buggy, in which case if a private libgcc is a fix, then by all means we
should use it.
And whenever we find that a GCC toolchain is provably buggy, we should
raise a bug, either to the toolchain provider if the issue is only with
a given binary release (e.g. mismatched or badly supported endianness),
or to the GCC project if the bug is inherent to GCC (e.g. generation
of non-supported opcodes for a given arch/cpu).
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 12:53 ` Albert ARIBAUD
@ 2016-03-23 13:22 ` Tom Rini
2016-03-23 17:08 ` Albert ARIBAUD
0 siblings, 1 reply; 40+ messages in thread
From: Tom Rini @ 2016-03-23 13:22 UTC (permalink / raw)
To: u-boot
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 <marex@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.
> Also, libgcc is not a standalone project that can be frozen, forked or
> improved freely; it is an internal component of the GCC toolchain. No
> standard defines what libgcc is or should be, and we have no control
> over the 'contract' between GCC-emitted code and libgcc. The GCC
> project may decide to change that contract at any time, and produce a
> new toolchain and a new libgcc. Using our private libgcc by default
> will cause all targets to break for no good reason. We've already been
> bitten by internal GCC changes on which we were dependent; adding more
> such dependency is not the way to go IMO.
>
> If we truly fear that GCC is *generally* unable to properly build our
> targets due to its libgcc, then we should not only "snapshot and fix"
> libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> sure we keep a consistent copy of it. I don't think that would be a
> viable move.
>
> And if we don't believe that GCC is generally unable to properly build
> U-Boot, then we should always use it as provided unless it is provably
> buggy, in which case if a private libgcc is a fix, then by all means we
> should use it.
>
> And whenever we find that a GCC toolchain is provably buggy, we should
> raise a bug, either to the toolchain provider if the issue is only with
> a given binary release (e.g. mismatched or badly supported endianness),
> or to the GCC project if the bug is inherent to GCC (e.g. generation
> of non-supported opcodes for a given arch/cpu).
Ah, but this shows part of the problem. We don't need "libgcc" as in
"the thing which provides gcc'isms". We need "libgcc" as in "the thing
which provides AEABI functions". Today we get these from libgcc but we
run into cases where this doesn't work quite right (toolchain fun) or
simply aren't available (again, clang). So I am in favour of re-syncing
with this part of the kernel and mirroring the decision to always
include these functions, again, like the kernel does.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160323/60bbeb08/attachment.sig>
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 13:22 ` Tom Rini
@ 2016-03-23 17:08 ` Albert ARIBAUD
2016-03-23 21:36 ` Tom Rini
0 siblings, 1 reply; 40+ messages in thread
From: Albert ARIBAUD @ 2016-03-23 17:08 UTC (permalink / raw)
To: u-boot
Hello Tom,
On Wed, 23 Mar 2016 09:22:38 -0400, Tom Rini <trini@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 <marex@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?
> > Also, libgcc is not a standalone project that can be frozen, forked or
> > improved freely; it is an internal component of the GCC toolchain. No
> > standard defines what libgcc is or should be, and we have no control
> > over the 'contract' between GCC-emitted code and libgcc. The GCC
> > project may decide to change that contract at any time, and produce a
> > new toolchain and a new libgcc. Using our private libgcc by default
> > will cause all targets to break for no good reason. We've already been
> > bitten by internal GCC changes on which we were dependent; adding more
> > such dependency is not the way to go IMO.
> >
> > If we truly fear that GCC is *generally* unable to properly build our
> > targets due to its libgcc, then we should not only "snapshot and fix"
> > libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> > sure we keep a consistent copy of it. I don't think that would be a
> > viable move.
> >
> > And if we don't believe that GCC is generally unable to properly build
> > U-Boot, then we should always use it as provided unless it is provably
> > buggy, in which case if a private libgcc is a fix, then by all means we
> > should use it.
> >
> > And whenever we find that a GCC toolchain is provably buggy, we should
> > raise a bug, either to the toolchain provider if the issue is only with
> > a given binary release (e.g. mismatched or badly supported endianness),
> > or to the GCC project if the bug is inherent to GCC (e.g. generation
> > of non-supported opcodes for a given arch/cpu).
>
> Ah, but this shows part of the problem. We don't need "libgcc" as in
> "the thing which provides gcc'isms". We need "libgcc" as in "the thing
> which provides AEABI functions".
Not sure I'm getting what you mean. For one thing, I don't see that
AEABI specifies any functions. Also, I don't see where it is established
that U-Boot "needs AEABI functions". Finally, I don't see that libgcc
is a standalone project aiming at providing AEABI functions.
> Today we get these from libgcc but we
> run into cases where this doesn't work quite right (toolchain fun) or
> simply aren't available (again, clang). So I am in favour of re-syncing
> with this part of the kernel and mirroring the decision to always
> include these functions, again, like the kernel does.
If we are using libgcc for providing AEABI services then we are using it
wrong. Its role is to support GCC-generated code.
Could you give me an example of this "need for [an] AEABI function"?
> --
> Tom
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 17:08 ` Albert ARIBAUD
@ 2016-03-23 21:36 ` Tom Rini
2016-03-23 23:02 ` Sergey Kubushyn
2016-03-24 7:50 ` Albert ARIBAUD
0 siblings, 2 replies; 40+ messages in thread
From: Tom Rini @ 2016-03-23 21:36 UTC (permalink / raw)
To: u-boot
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 <trini@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 <marex@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
> > > Also, libgcc is not a standalone project that can be frozen, forked or
> > > improved freely; it is an internal component of the GCC toolchain. No
> > > standard defines what libgcc is or should be, and we have no control
> > > over the 'contract' between GCC-emitted code and libgcc. The GCC
> > > project may decide to change that contract at any time, and produce a
> > > new toolchain and a new libgcc. Using our private libgcc by default
> > > will cause all targets to break for no good reason. We've already been
> > > bitten by internal GCC changes on which we were dependent; adding more
> > > such dependency is not the way to go IMO.
> > >
> > > If we truly fear that GCC is *generally* unable to properly build our
> > > targets due to its libgcc, then we should not only "snapshot and fix"
> > > libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> > > sure we keep a consistent copy of it. I don't think that would be a
> > > viable move.
> > >
> > > And if we don't believe that GCC is generally unable to properly build
> > > U-Boot, then we should always use it as provided unless it is provably
> > > buggy, in which case if a private libgcc is a fix, then by all means we
> > > should use it.
> > >
> > > And whenever we find that a GCC toolchain is provably buggy, we should
> > > raise a bug, either to the toolchain provider if the issue is only with
> > > a given binary release (e.g. mismatched or badly supported endianness),
> > > or to the GCC project if the bug is inherent to GCC (e.g. generation
> > > of non-supported opcodes for a given arch/cpu).
> >
> > Ah, but this shows part of the problem. We don't need "libgcc" as in
> > "the thing which provides gcc'isms". We need "libgcc" as in "the thing
> > which provides AEABI functions".
>
> Not sure I'm getting what you mean. For one thing, I don't see that
> AEABI specifies any functions. Also, I don't see where it is established
> that U-Boot "needs AEABI functions". Finally, I don't see that libgcc
> is a standalone project aiming at providing AEABI functions.
Well, lets unpack things in the order that it matters. If we kludge the
toplevel Makefile to not set CONFIG_USE_PRIVATE_LIBGCC nor link in
libgcc on ARM, and build work_92105 with an arm-none-eabi GCC we start
failing on:
arch/arm/cpu/arm926ejs/built-in.o: In function `print_cpuinfo':
/home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:64:
undefined reference to `__aeabi_uidiv'
/home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:65:
undefined reference to `__aeabi_uidiv'
/home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:66:
undefined reference to `__aeabi_uidiv'
and fail on and on from there (I see several pages). Line 64-66 are:
printf("CPU clock: %uMHz\n", get_hclk_pll_rate() / 1000000);
printf("AHB bus clock: %uMHz\n", get_hclk_clk_rate() / 1000000);
printf("Peripheral clock: %uMHz\n", get_periph_clk_rate() / 1000000);
So, despite being "freestanding" and requring "no builtins" we still
requiring the toolchain to give us these functions separately, or just
bring them ourself. Note that ARC, SH and MIPS all always follow the
kernel model of just providing these bits of functionality rather than
rely on getting just those things from libgcc.
> > Today we get these from libgcc but we
> > run into cases where this doesn't work quite right (toolchain fun) or
> > simply aren't available (again, clang). So I am in favour of re-syncing
> > with this part of the kernel and mirroring the decision to always
> > include these functions, again, like the kernel does.
>
> If we are using libgcc for providing AEABI services then we are using it
> wrong. Its role is to support GCC-generated code.
>
> Could you give me an example of this "need for [an] AEABI function"?
See above. And yes, we're using libgcc wrong by IMHO using it at all.
We don't need it and opt out of it for almost everything, except for the
above.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160323/f7b48fa7/attachment.sig>
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 21:36 ` Tom Rini
@ 2016-03-23 23:02 ` Sergey Kubushyn
2016-03-23 23:08 ` Tom Rini
2016-03-24 7:50 ` Albert ARIBAUD
1 sibling, 1 reply; 40+ messages in thread
From: Sergey Kubushyn @ 2016-03-23 23:02 UTC (permalink / raw)
To: u-boot
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 <trini@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 <marex@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 at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 23:02 ` Sergey Kubushyn
@ 2016-03-23 23:08 ` Tom Rini
2016-03-23 23:24 ` Sergey Kubushyn
2016-03-23 23:24 ` Marek Vasut
0 siblings, 2 replies; 40+ messages in thread
From: Tom Rini @ 2016-03-23 23:08 UTC (permalink / raw)
To: u-boot
On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
> 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 <trini@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 <marex@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.
Well, this is an example of why we both don't want libgcc ever nor do we
want to overly expand what we do offer. In this case isn't it an
example of something that should be using lldiv/do_div/etc?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160323/ecd3e979/attachment.sig>
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 23:08 ` Tom Rini
@ 2016-03-23 23:24 ` Sergey Kubushyn
2016-03-23 23:24 ` Marek Vasut
1 sibling, 0 replies; 40+ messages in thread
From: Sergey Kubushyn @ 2016-03-23 23:24 UTC (permalink / raw)
To: u-boot
On Wed, 23 Mar 2016, Tom Rini wrote:
> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>> 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 <trini@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 <marex@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.
>
> Well, this is an example of why we both don't want libgcc ever nor do we
> want to overly expand what we do offer. In this case isn't it an
> example of something that should be using lldiv/do_div/etc?
It is. However do_div does not help for some reason -- here is an excerpt
from drivers/video/ipu_common.c (one of several places where do_div() is
used) that pulls _udivmoddi4 from toolchain anyways:
=== Cut ===
static void ipu_pixel_clk_recalc(struct clk *clk)
{
u32 div;
u64 final_rate = (unsigned long long)clk->parent->rate * 16;
div = __raw_readl(DI_BS_CLKGEN0(clk->id));
debug("read BS_CLKGEN0 div:%d, final_rate:%lld, prate:%ld\n",
div, final_rate, clk->parent->rate);
clk->rate = 0;
if (div != 0) {
do_div(final_rate, div);
clk->rate = final_rate;
}
}
=== Cut ===
Without the above hack this results in link failure:
=== Cut ===
arm-linux-gnueabi-ld.bfd: error: /opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o) uses VFP register arguments, u-boot does not
arm-linux-gnueabi-ld.bfd: failed to merge target specific data of file /opt/arm-linux-toolchain/lib/gcc/arm-linux-gnueabi/5.3.0/libgcc.a(_udivmoddi4.o)
Makefile:1191: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1
=== Cut ===
U-Boot built with "-mfloat-abi=hard -mfpu=vfpv3-d16" pulls whatever it
requires from toolchain libgcc and works fine, no problems.
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 23:08 ` Tom Rini
2016-03-23 23:24 ` Sergey Kubushyn
@ 2016-03-23 23:24 ` Marek Vasut
2016-03-23 23:47 ` Sergey Kubushyn
1 sibling, 1 reply; 40+ messages in thread
From: Marek Vasut @ 2016-03-23 23:24 UTC (permalink / raw)
To: u-boot
On 03/24/2016 12:08 AM, Tom Rini wrote:
> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>> 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 <trini@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 <marex@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.
>
> Well, this is an example of why we both don't want libgcc ever nor do we
> want to overly expand what we do offer. In this case isn't it an
> example of something that should be using lldiv/do_div/etc?
I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
also doesn't implement the function. Which toolchain do you use and
which target did you compile?
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 23:24 ` Marek Vasut
@ 2016-03-23 23:47 ` Sergey Kubushyn
2016-03-23 23:49 ` Marek Vasut
0 siblings, 1 reply; 40+ messages in thread
From: Sergey Kubushyn @ 2016-03-23 23:47 UTC (permalink / raw)
To: u-boot
On Thu, 24 Mar 2016, Marek Vasut wrote:
> On 03/24/2016 12:08 AM, Tom Rini wrote:
>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>>> 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 <trini@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 <marex@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.
>>
>> Well, this is an example of why we both don't want libgcc ever nor do we
>> want to overly expand what we do offer. In this case isn't it an
>> example of something that should be using lldiv/do_div/etc?
>
> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
> also doesn't implement the function. Which toolchain do you use and
> which target did you compile?
I'm using my own armv7hl-linux-gnueabi toolchain built for hard float. Linux
arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
function that is used by do_div() from include/asm/div64.h for 32-bit ARM
platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
(that is totally different from what Linux provides) but no div64.S in
arch/arm/lib.
The target is a custom board based on Freescale/NXP mx6qsabresd (I'm not
ready to submit it to the main tree yet) so sabresd should produce the same
result. Just have IPU enabled.
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 23:47 ` Sergey Kubushyn
@ 2016-03-23 23:49 ` Marek Vasut
2016-03-23 23:54 ` Sergey Kubushyn
2016-03-24 0:13 ` Tom Rini
0 siblings, 2 replies; 40+ messages in thread
From: Marek Vasut @ 2016-03-23 23:49 UTC (permalink / raw)
To: u-boot
On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
> On Thu, 24 Mar 2016, Marek Vasut wrote:
>
>> On 03/24/2016 12:08 AM, Tom Rini wrote:
>>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>>>> 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 <trini@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 <marex@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.
>>>
>>> Well, this is an example of why we both don't want libgcc ever nor do we
>>> want to overly expand what we do offer. In this case isn't it an
>>> example of something that should be using lldiv/do_div/etc?
>>
>> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
>> also doesn't implement the function. Which toolchain do you use and
>> which target did you compile?
>
> I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
> Linux
> arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
> function that is used by do_div() from include/asm/div64.h for 32-bit ARM
> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
> (that is totally different from what Linux provides) but no div64.S in
> arch/arm/lib.
In that case, we should just import div64.S from Linux on arm32 and be
done with it ? Since we now have all the necessary macros thanks to the
first four patches in this series, that should be trivial.
What do you think? I can bake a patch real quick, so you can test it ?
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 23:49 ` Marek Vasut
@ 2016-03-23 23:54 ` Sergey Kubushyn
2016-03-24 0:10 ` [U-Boot] [PATCH] arm: lib: Import __do_div64 from Linux Marek Vasut
2016-03-24 0:11 ` [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default Marek Vasut
2016-03-24 0:13 ` Tom Rini
1 sibling, 2 replies; 40+ messages in thread
From: Sergey Kubushyn @ 2016-03-23 23:54 UTC (permalink / raw)
To: u-boot
On Thu, 24 Mar 2016, Marek Vasut wrote:
> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>
>>> On 03/24/2016 12:08 AM, Tom Rini wrote:
>>>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>>>>> 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 <trini@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 <marex@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.
>>>>
>>>> Well, this is an example of why we both don't want libgcc ever nor do we
>>>> want to overly expand what we do offer. In this case isn't it an
>>>> example of something that should be using lldiv/do_div/etc?
>>>
>>> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
>>> also doesn't implement the function. Which toolchain do you use and
>>> which target did you compile?
>>
>> I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
>> Linux
>> arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
>> function that is used by do_div() from include/asm/div64.h for 32-bit ARM
>> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
>> (that is totally different from what Linux provides) but no div64.S in
>> arch/arm/lib.
>
> In that case, we should just import div64.S from Linux on arm32 and be
> done with it ? Since we now have all the necessary macros thanks to the
> first four patches in this series, that should be trivial.
>
> What do you think? I can bake a patch real quick, so you can test it ?
Sure I'll test it, no problems. Just bake the patch :)
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH] arm: lib: Import __do_div64 from Linux
2016-03-23 23:54 ` Sergey Kubushyn
@ 2016-03-24 0:10 ` Marek Vasut
2016-03-24 0:11 ` [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default Marek Vasut
1 sibling, 0 replies; 40+ messages in thread
From: Marek Vasut @ 2016-03-24 0:10 UTC (permalink / raw)
To: u-boot
Import __do_div64 from Linux 4.4.6 , commit 0d1912303e54ed1b2a371be0bba51c384dd57326
on arm32. This function is for some toolchains, which generate _udivmoddi4()
for 64 bit division.
Since we do not support stack unwinding, instead of importing the whole
asm/unwind.h and all the baggage, this patch defines empty UNWIND() macro.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: ksi at koi8.net
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
---
arch/arm/lib/Makefile | 2 +-
arch/arm/lib/div64.S | 214 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 215 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/lib/div64.S
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index dce6ff9..29c2f2b 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -6,7 +6,7 @@
#
lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o \
- lib1funcs.o uldivmod.o div0.o
+ lib1funcs.o uldivmod.o div0.o div64.o
ifdef CONFIG_CPU_V7M
obj-y += vectors_m.o crt0.o
diff --git a/arch/arm/lib/div64.S b/arch/arm/lib/div64.S
new file mode 100644
index 0000000..f238bc6
--- /dev/null
+++ b/arch/arm/lib/div64.S
@@ -0,0 +1,214 @@
+/*
+ * linux/arch/arm/lib/div64.S
+ *
+ * Optimized computation of 64-bit dividend / 32-bit divisor
+ *
+ * Author: Nicolas Pitre
+ * Created: Oct 5, 2003
+ * Copyright: Monta Vista Software, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/linkage.h>
+#include <asm/assembler.h>
+#ifdef __UBOOT__
+#define UNWIND(x...)
+#endif
+
+#ifdef __ARMEB__
+#define xh r0
+#define xl r1
+#define yh r2
+#define yl r3
+#else
+#define xl r0
+#define xh r1
+#define yl r2
+#define yh r3
+#endif
+
+/*
+ * __do_div64: perform a division with 64-bit dividend and 32-bit divisor.
+ *
+ * Note: Calling convention is totally non standard for optimal code.
+ * This is meant to be used by do_div() from include/asm/div64.h only.
+ *
+ * Input parameters:
+ * xh-xl = dividend (clobbered)
+ * r4 = divisor (preserved)
+ *
+ * Output values:
+ * yh-yl = result
+ * xh = remainder
+ *
+ * Clobbered regs: xl, ip
+ */
+
+ENTRY(__do_div64)
+UNWIND(.fnstart)
+
+ @ Test for easy paths first.
+ subs ip, r4, #1
+ bls 9f @ divisor is 0 or 1
+ tst ip, r4
+ beq 8f @ divisor is power of 2
+
+ @ See if we need to handle upper 32-bit result.
+ cmp xh, r4
+ mov yh, #0
+ blo 3f
+
+ @ Align divisor with upper part of dividend.
+ @ The aligned divisor is stored in yl preserving the original.
+ @ The bit position is stored in ip.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+ clz yl, r4
+ clz ip, xh
+ sub yl, yl, ip
+ mov ip, #1
+ mov ip, ip, lsl yl
+ mov yl, r4, lsl yl
+
+#else
+
+ mov yl, r4
+ mov ip, #1
+1: cmp yl, #0x80000000
+ cmpcc yl, xh
+ movcc yl, yl, lsl #1
+ movcc ip, ip, lsl #1
+ bcc 1b
+
+#endif
+
+ @ The division loop for needed upper bit positions.
+ @ Break out early if dividend reaches 0.
+2: cmp xh, yl
+ orrcs yh, yh, ip
+ subcss xh, xh, yl
+ movnes ip, ip, lsr #1
+ mov yl, yl, lsr #1
+ bne 2b
+
+ @ See if we need to handle lower 32-bit result.
+3: cmp xh, #0
+ mov yl, #0
+ cmpeq xl, r4
+ movlo xh, xl
+ retlo lr
+
+ @ The division loop for lower bit positions.
+ @ Here we shift remainer bits leftwards rather than moving the
+ @ divisor for comparisons, considering the carry-out bit as well.
+ mov ip, #0x80000000
+4: movs xl, xl, lsl #1
+ adcs xh, xh, xh
+ beq 6f
+ cmpcc xh, r4
+5: orrcs yl, yl, ip
+ subcs xh, xh, r4
+ movs ip, ip, lsr #1
+ bne 4b
+ ret lr
+
+ @ The top part of remainder became zero. If carry is set
+ @ (the 33th bit) this is a false positive so resume the loop.
+ @ Otherwise, if lower part is also null then we are done.
+6: bcs 5b
+ cmp xl, #0
+ reteq lr
+
+ @ We still have remainer bits in the low part. Bring them up.
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+ clz xh, xl @ we know xh is zero here so...
+ add xh, xh, #1
+ mov xl, xl, lsl xh
+ mov ip, ip, lsr xh
+
+#else
+
+7: movs xl, xl, lsl #1
+ mov ip, ip, lsr #1
+ bcc 7b
+
+#endif
+
+ @ Current remainder is now 1. It is worthless to compare with
+ @ divisor at this point since divisor can not be smaller than 3 here.
+ @ If possible, branch for another shift in the division loop.
+ @ If no bit position left then we are done.
+ movs ip, ip, lsr #1
+ mov xh, #1
+ bne 4b
+ ret lr
+
+8: @ Division by a power of 2: determine what that divisor order is
+ @ then simply shift values around
+
+#if __LINUX_ARM_ARCH__ >= 5
+
+ clz ip, r4
+ rsb ip, ip, #31
+
+#else
+
+ mov yl, r4
+ cmp r4, #(1 << 16)
+ mov ip, #0
+ movhs yl, yl, lsr #16
+ movhs ip, #16
+
+ cmp yl, #(1 << 8)
+ movhs yl, yl, lsr #8
+ addhs ip, ip, #8
+
+ cmp yl, #(1 << 4)
+ movhs yl, yl, lsr #4
+ addhs ip, ip, #4
+
+ cmp yl, #(1 << 2)
+ addhi ip, ip, #3
+ addls ip, ip, yl, lsr #1
+
+#endif
+
+ mov yh, xh, lsr ip
+ mov yl, xl, lsr ip
+ rsb ip, ip, #32
+ ARM( orr yl, yl, xh, lsl ip )
+ THUMB( lsl xh, xh, ip )
+ THUMB( orr yl, yl, xh )
+ mov xh, xl, lsl ip
+ mov xh, xh, lsr ip
+ ret lr
+
+ @ eq -> division by 1: obvious enough...
+9: moveq yl, xl
+ moveq yh, xh
+ moveq xh, #0
+ reteq lr
+UNWIND(.fnend)
+
+UNWIND(.fnstart)
+UNWIND(.pad #4)
+UNWIND(.save {lr})
+Ldiv0_64:
+ @ Division by 0:
+ str lr, [sp, #-8]!
+ bl __div0
+
+ @ as wrong as it could be...
+ mov yl, #0
+ mov yh, #0
+ mov xh, #0
+ ldr pc, [sp], #8
+
+UNWIND(.fnend)
+ENDPROC(__do_div64)
--
2.7.0
^ permalink raw reply related [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 23:54 ` Sergey Kubushyn
2016-03-24 0:10 ` [U-Boot] [PATCH] arm: lib: Import __do_div64 from Linux Marek Vasut
@ 2016-03-24 0:11 ` Marek Vasut
2016-03-24 2:28 ` Sergey Kubushyn
2016-03-24 18:18 ` Sergey Kubushyn
1 sibling, 2 replies; 40+ messages in thread
From: Marek Vasut @ 2016-03-24 0:11 UTC (permalink / raw)
To: u-boot
On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:
> On Thu, 24 Mar 2016, Marek Vasut wrote:
>
>> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>
>>>> On 03/24/2016 12:08 AM, Tom Rini wrote:
>>>>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>>>>>> 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 <trini@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 <marex@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.
>>>>>
>>>>> Well, this is an example of why we both don't want libgcc ever nor
>>>>> do we
>>>>> want to overly expand what we do offer. In this case isn't it an
>>>>> example of something that should be using lldiv/do_div/etc?
>>>>
>>>> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
>>>> also doesn't implement the function. Which toolchain do you use and
>>>> which target did you compile?
>>>
>>> I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
>>> Linux
>>> arm libgcc does have arch/arm/lib/div64.S file that provides
>>> __do_div64()
>>> function that is used by do_div() from include/asm/div64.h for 32-bit
>>> ARM
>>> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have
>>> div64.h
>>> (that is totally different from what Linux provides) but no div64.S in
>>> arch/arm/lib.
>>
>> In that case, we should just import div64.S from Linux on arm32 and be
>> done with it ? Since we now have all the necessary macros thanks to the
>> first four patches in this series, that should be trivial.
>>
>> What do you think? I can bake a patch real quick, so you can test it ?
>
> Sure I'll test it, no problems. Just bake the patch :)
Done, give it a go please.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 23:49 ` Marek Vasut
2016-03-23 23:54 ` Sergey Kubushyn
@ 2016-03-24 0:13 ` Tom Rini
2016-03-24 0:36 ` Marek Vasut
1 sibling, 1 reply; 40+ messages in thread
From: Tom Rini @ 2016-03-24 0:13 UTC (permalink / raw)
To: u-boot
On Thu, Mar 24, 2016 at 12:49:54AM +0100, Marek Vasut wrote:
> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
> > On Thu, 24 Mar 2016, Marek Vasut wrote:
> >
> >> On 03/24/2016 12:08 AM, Tom Rini wrote:
> >>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
> >>>> 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 <trini@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 <marex@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.
> >>>
> >>> Well, this is an example of why we both don't want libgcc ever nor do we
> >>> want to overly expand what we do offer. In this case isn't it an
> >>> example of something that should be using lldiv/do_div/etc?
> >>
> >> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
> >> also doesn't implement the function. Which toolchain do you use and
> >> which target did you compile?
> >
> > I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
> > Linux
> > arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
> > function that is used by do_div() from include/asm/div64.h for 32-bit ARM
> > platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
> > (that is totally different from what Linux provides) but no div64.S in
> > arch/arm/lib.
>
> In that case, we should just import div64.S from Linux on arm32 and be
> done with it ? Since we now have all the necessary macros thanks to the
> first four patches in this series, that should be trivial.
>
> What do you think? I can bake a patch real quick, so you can test it ?
Follow-up _series_ to re-sync our 64bit math stuff with the kernel.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160323/87110bec/attachment.sig>
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-24 0:13 ` Tom Rini
@ 2016-03-24 0:36 ` Marek Vasut
0 siblings, 0 replies; 40+ messages in thread
From: Marek Vasut @ 2016-03-24 0:36 UTC (permalink / raw)
To: u-boot
On 03/24/2016 01:13 AM, Tom Rini wrote:
> On Thu, Mar 24, 2016 at 12:49:54AM +0100, Marek Vasut wrote:
>> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>
>>>> On 03/24/2016 12:08 AM, Tom Rini wrote:
>>>>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>>>>>> 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 <trini@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 <marex@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.
>>>>>
>>>>> Well, this is an example of why we both don't want libgcc ever nor do we
>>>>> want to overly expand what we do offer. In this case isn't it an
>>>>> example of something that should be using lldiv/do_div/etc?
>>>>
>>>> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
>>>> also doesn't implement the function. Which toolchain do you use and
>>>> which target did you compile?
>>>
>>> I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
>>> Linux
>>> arm libgcc does have arch/arm/lib/div64.S file that provides __do_div64()
>>> function that is used by do_div() from include/asm/div64.h for 32-bit ARM
>>> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have div64.h
>>> (that is totally different from what Linux provides) but no div64.S in
>>> arch/arm/lib.
>>
>> In that case, we should just import div64.S from Linux on arm32 and be
>> done with it ? Since we now have all the necessary macros thanks to the
>> first four patches in this series, that should be trivial.
>>
>> What do you think? I can bake a patch real quick, so you can test it ?
>
> Follow-up _series_ to re-sync our 64bit math stuff with the kernel.
>
Something tells me this is gonna be one patch , not a series.
--
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-24 0:11 ` [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default Marek Vasut
@ 2016-03-24 2:28 ` Sergey Kubushyn
2016-03-24 18:18 ` Sergey Kubushyn
1 sibling, 0 replies; 40+ messages in thread
From: Sergey Kubushyn @ 2016-03-24 2:28 UTC (permalink / raw)
To: u-boot
On Thu, 24 Mar 2016, Marek Vasut wrote:
> On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:
>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>
>>> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>>
>>>>> On 03/24/2016 12:08 AM, Tom Rini wrote:
>>>>>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>>>>>>> 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 <trini@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 <marex@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.
>>>>>>
>>>>>> Well, this is an example of why we both don't want libgcc ever nor
>>>>>> do we
>>>>>> want to overly expand what we do offer. In this case isn't it an
>>>>>> example of something that should be using lldiv/do_div/etc?
>>>>>
>>>>> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
>>>>> also doesn't implement the function. Which toolchain do you use and
>>>>> which target did you compile?
>>>>
>>>> I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
>>>> Linux
>>>> arm libgcc does have arch/arm/lib/div64.S file that provides
>>>> __do_div64()
>>>> function that is used by do_div() from include/asm/div64.h for 32-bit
>>>> ARM
>>>> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have
>>>> div64.h
>>>> (that is totally different from what Linux provides) but no div64.S in
>>>> arch/arm/lib.
>>>
>>> In that case, we should just import div64.S from Linux on arm32 and be
>>> done with it ? Since we now have all the necessary macros thanks to the
>>> first four patches in this series, that should be trivial.
>>>
>>> What do you think? I can bake a patch real quick, so you can test it ?
>>
>> Sure I'll test it, no problems. Just bake the patch :)
>
> Done, give it a go please.
Will do first thing tomorrow morning when I'm back at my work desk. Will
post the results when done.
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-23 21:36 ` Tom Rini
2016-03-23 23:02 ` Sergey Kubushyn
@ 2016-03-24 7:50 ` Albert ARIBAUD
2016-03-25 0:49 ` Tom Rini
1 sibling, 1 reply; 40+ messages in thread
From: Albert ARIBAUD @ 2016-03-24 7:50 UTC (permalink / raw)
To: u-boot
Hello Tom,
On Wed, 23 Mar 2016 17:36:17 -0400, Tom Rini <trini@konsulko.com> 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 <trini@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 <marex@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
(ok, that explains what you mean by AEABI functions -- those are
actually not functions defined by the AEABI, but functions that the GCC
folks prefixed with __aeabi.)
I do understand that clang does not provide these functions. What I
want to understand is how come code compiled by clang would need them
unless we introduced that dependency ourselves. clang does produce
correct and self-sufficient code when using 64-bit division, right?
> > > > Also, libgcc is not a standalone project that can be frozen, forked or
> > > > improved freely; it is an internal component of the GCC toolchain. No
> > > > standard defines what libgcc is or should be, and we have no control
> > > > over the 'contract' between GCC-emitted code and libgcc. The GCC
> > > > project may decide to change that contract at any time, and produce a
> > > > new toolchain and a new libgcc. Using our private libgcc by default
> > > > will cause all targets to break for no good reason. We've already been
> > > > bitten by internal GCC changes on which we were dependent; adding more
> > > > such dependency is not the way to go IMO.
> > > >
> > > > If we truly fear that GCC is *generally* unable to properly build our
> > > > targets due to its libgcc, then we should not only "snapshot and fix"
> > > > libgcc; we should "snapshot and fix" the whole GCC toolchain, to make
> > > > sure we keep a consistent copy of it. I don't think that would be a
> > > > viable move.
> > > >
> > > > And if we don't believe that GCC is generally unable to properly build
> > > > U-Boot, then we should always use it as provided unless it is provably
> > > > buggy, in which case if a private libgcc is a fix, then by all means we
> > > > should use it.
> > > >
> > > > And whenever we find that a GCC toolchain is provably buggy, we should
> > > > raise a bug, either to the toolchain provider if the issue is only with
> > > > a given binary release (e.g. mismatched or badly supported endianness),
> > > > or to the GCC project if the bug is inherent to GCC (e.g. generation
> > > > of non-supported opcodes for a given arch/cpu).
> > >
> > > Ah, but this shows part of the problem. We don't need "libgcc" as in
> > > "the thing which provides gcc'isms". We need "libgcc" as in "the thing
> > > which provides AEABI functions".
> >
> > Not sure I'm getting what you mean. For one thing, I don't see that
> > AEABI specifies any functions. Also, I don't see where it is established
> > that U-Boot "needs AEABI functions". Finally, I don't see that libgcc
> > is a standalone project aiming at providing AEABI functions.
>
> Well, lets unpack things in the order that it matters. If we kludge the
> toplevel Makefile to not set CONFIG_USE_PRIVATE_LIBGCC nor link in
> libgcc on ARM, and build work_92105 with an arm-none-eabi GCC we start
> failing on:
Here you are actively setting the conditions for the build to fail
since you prevent the linker from using *any* libgcc implentation
despite knowing that the generated code requires one.
> arch/arm/cpu/arm926ejs/built-in.o: In function `print_cpuinfo':
> /home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:64:
> undefined reference to `__aeabi_uidiv'
> /home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:65:
> undefined reference to `__aeabi_uidiv'
> /home/trini/work/u-boot/u-boot/arch/arm/cpu/arm926ejs/lpc32xx/cpu.c:66:
> undefined reference to `__aeabi_uidiv'
> and fail on and on from there (I see several pages). Line 64-66 are:
> printf("CPU clock: %uMHz\n", get_hclk_pll_rate() / 1000000);
> printf("AHB bus clock: %uMHz\n", get_hclk_clk_rate() / 1000000);
> printf("Peripheral clock: %uMHz\n", get_periph_clk_rate() / 1000000);
Do these errors occur when you do not actively prevent any libgcc from
linking? Do they occur when you do not prevent GCC's libgcc from linking?
> So, despite being "freestanding" and requring "no builtins" we still
> requiring the toolchain to give us these functions separately, or just
> bring them ourself. Note that ARC, SH and MIPS all always follow the
> kernel model of just providing these bits of functionality rather than
> rely on getting just those things from libgcc.
Yes, we do require the toolchain to provide these functions, or more to
the point, we need to not prevent the toolchain from building our code
as it was designed to; and the toolchain was designed to generate code
which refers to symbols defined in a library that must be linked with
that code; and the toolchain provides that library as "libgcc". That is
exactly my point: the toolchain requires *and provides* libgcc. That's
an internal design-induced requirement, and users of the toolchain
should not even have to meddle with it unless broken.
Again, I an fine with private libgcc as a fix to specific case of
buggy toolchain releases. What I am not fine with is replacing a third
party tool's mechanism with our own when this mechanism works.
> > > Today we get these from libgcc but we
> > > run into cases where this doesn't work quite right (toolchain fun) or
> > > simply aren't available (again, clang). So I am in favour of re-syncing
> > > with this part of the kernel and mirroring the decision to always
> > > include these functions, again, like the kernel does.
> >
> > If we are using libgcc for providing AEABI services then we are using it
> > wrong. Its role is to support GCC-generated code.
> >
> > Could you give me an example of this "need for [an] AEABI function"?
>
> See above. And yes, we're using libgcc wrong by IMHO using it at all.
And I think your view of what libgcc is is wrong. It is not something
*we* use, it is something that *GCC* uses by design. And it is not
something that we have a choice in using as long as we build with GCC.
> We don't need it and opt out of it for almost everything, except for the
> above.
We do need libgcc as long as we use GCC. The best proof is the
contrived build above, which you can reproduce with *any* GCC build,
cross or native, for bare metal code or for a Linux Hello World
application: when we actively deprive GCC from the libgcc that it
requires and provides, it won't work, exactly like when we remove gas
from a car, it won't run.
> --
> Tom
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-24 0:11 ` [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default Marek Vasut
2016-03-24 2:28 ` Sergey Kubushyn
@ 2016-03-24 18:18 ` Sergey Kubushyn
2016-03-24 18:43 ` Sergey Kubushyn
1 sibling, 1 reply; 40+ messages in thread
From: Sergey Kubushyn @ 2016-03-24 18:18 UTC (permalink / raw)
To: u-boot
On Thu, 24 Mar 2016, Marek Vasut wrote:
> On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:
>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>
>>> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>>
>>>>> On 03/24/2016 12:08 AM, Tom Rini wrote:
>>>>>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>>>>>>> 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 <trini@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 <marex@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.
>>>>>>
>>>>>> Well, this is an example of why we both don't want libgcc ever nor
>>>>>> do we
>>>>>> want to overly expand what we do offer. In this case isn't it an
>>>>>> example of something that should be using lldiv/do_div/etc?
>>>>>
>>>>> I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc copy
>>>>> also doesn't implement the function. Which toolchain do you use and
>>>>> which target did you compile?
>>>>
>>>> I'm using my own armv7hl-linux-gnueabi toolchain built for hard float.
>>>> Linux
>>>> arm libgcc does have arch/arm/lib/div64.S file that provides
>>>> __do_div64()
>>>> function that is used by do_div() from include/asm/div64.h for 32-bit
>>>> ARM
>>>> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have
>>>> div64.h
>>>> (that is totally different from what Linux provides) but no div64.S in
>>>> arch/arm/lib.
>>>
>>> In that case, we should just import div64.S from Linux on arm32 and be
>>> done with it ? Since we now have all the necessary macros thanks to the
>>> first four patches in this series, that should be trivial.
>>>
>>> What do you think? I can bake a patch real quick, so you can test it ?
>>
>> Sure I'll test it, no problems. Just bake the patch :)
>
> Done, give it a go please.
OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm
analyzing it right now, will come up with more later today.
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-24 18:18 ` Sergey Kubushyn
@ 2016-03-24 18:43 ` Sergey Kubushyn
2016-03-24 19:04 ` Marek Vasut
0 siblings, 1 reply; 40+ messages in thread
From: Sergey Kubushyn @ 2016-03-24 18:43 UTC (permalink / raw)
To: u-boot
On Thu, 24 Mar 2016, Sergey Kubushyn wrote:
> On Thu, 24 Mar 2016, Marek Vasut wrote:
>
>> On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:
>> > On Thu, 24 Mar 2016, Marek Vasut wrote:
>> >
>> > > On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>> > > > On Thu, 24 Mar 2016, Marek Vasut wrote:
>> > > >
>> > > > > On 03/24/2016 12:08 AM, Tom Rini wrote:
>> > > > > > On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn wrote:
>> > > > > > > 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
>> > > > > > > > > <trini@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
>> > > > > > > > > > > <marex@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.
>> > > > > >
>> > > > > > Well, this is an example of why we both don't want libgcc ever
>> > > > > > nor
>> > > > > > do we
>> > > > > > want to overly expand what we do offer. In this case isn't it
>> > > > > > an
>> > > > > > example of something that should be using lldiv/do_div/etc?
>> > > > >
>> > > > > I haven't seen the _udivmoddi4 emitted in my tests. Linux's libgcc
>> > > > > copy
>> > > > > also doesn't implement the function. Which toolchain do you use
>> > > > > and
>> > > > > which target did you compile?
>> > > >
>> > > > I'm using my own armv7hl-linux-gnueabi toolchain built for hard
>> > > > float.
>> > > > Linux
>> > > > arm libgcc does have arch/arm/lib/div64.S file that provides
>> > > > __do_div64()
>> > > > function that is used by do_div() from include/asm/div64.h for
>> > > > 32-bit
>> > > > ARM
>> > > > platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_ have
>> > > > div64.h
>> > > > (that is totally different from what Linux provides) but no div64.S
>> > > > in
>> > > > arch/arm/lib.
>> > >
>> > > In that case, we should just import div64.S from Linux on arm32 and be
>> > > done with it ? Since we now have all the necessary macros thanks to
>> > > the
>> > > first four patches in this series, that should be trivial.
>> > >
>> > > What do you think? I can bake a patch real quick, so you can test it ?
>> >
>> > Sure I'll test it, no problems. Just bake the patch :)
>>
>> Done, give it a go please.
>
> OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm
> analyzing it right now, will come up with more later today.
OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private libgcc,
my bad -- thought it would be automatic. Having that defined makes build
fail complaining about assembly syntax in div64.S:
=== Cut ===
arch/arm/lib/div64.S: Assembler messages:
arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl ip)'
arch/arm/lib/div64.S:186: Error: bad instruction `thumb( lsl r1,r1,ip)'
arch/arm/lib/div64.S:187: Error: bad instruction `thumb( orr r2,r2,r1)'
scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o' failed
make[1]: *** [arch/arm/lib/div64.o] Error 1
Makefile:1214: recipe for target 'arch/arm/lib' failed
make: *** [arch/arm/lib] Error 2
=== Cut ===
Probably something is missing in div64.h? The Linux one is totally
different. Digging in right now...
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-24 18:43 ` Sergey Kubushyn
@ 2016-03-24 19:04 ` Marek Vasut
2016-03-24 19:08 ` Sergey Kubushyn
0 siblings, 1 reply; 40+ messages in thread
From: Marek Vasut @ 2016-03-24 19:04 UTC (permalink / raw)
To: u-boot
On 03/24/2016 07:43 PM, Sergey Kubushyn wrote:
> On Thu, 24 Mar 2016, Sergey Kubushyn wrote:
>
>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>
>>> On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:
>>> > On Thu, 24 Mar 2016, Marek Vasut wrote:
>>> > > > On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>>> > > > On Thu, 24 Mar 2016, Marek Vasut wrote:
>>> > > > > > > > On 03/24/2016 12:08 AM, Tom Rini wrote:
>>> > > > > > On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn
>>> wrote:
>>> > > > > > > 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 > > > > > > > > <trini@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 > > > > > > > > > > <marex@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.
>>> > > > > > > > > > > Well, this is an example of why we both don't
>>> want libgcc ever > > > > > nor
>>> > > > > > do we
>>> > > > > > want to overly expand what we do offer. In this case
>>> isn't it > > > > > an
>>> > > > > > example of something that should be using lldiv/do_div/etc?
>>> > > > > > > > > I haven't seen the _udivmoddi4 emitted in my tests.
>>> Linux's libgcc > > > > copy
>>> > > > > also doesn't implement the function. Which toolchain do you
>>> use > > > > and
>>> > > > > which target did you compile?
>>> > > > > > > I'm using my own armv7hl-linux-gnueabi toolchain built
>>> for hard > > > float.
>>> > > > Linux
>>> > > > arm libgcc does have arch/arm/lib/div64.S file that provides
>>> > > > __do_div64()
>>> > > > function that is used by do_div() from include/asm/div64.h for
>>> > > > 32-bit
>>> > > > ARM
>>> > > > platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_
>>> have
>>> > > > div64.h
>>> > > > (that is totally different from what Linux provides) but no
>>> div64.S > > > in
>>> > > > arch/arm/lib.
>>> > > > > In that case, we should just import div64.S from Linux on
>>> arm32 and be
>>> > > done with it ? Since we now have all the necessary macros thanks
>>> to > > the
>>> > > first four patches in this series, that should be trivial.
>>> > > > > What do you think? I can bake a patch real quick, so you can
>>> test it ?
>>> > > Sure I'll test it, no problems. Just bake the patch :)
>>>
>>> Done, give it a go please.
>>
>> OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm
>> analyzing it right now, will come up with more later today.
>
> OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private libgcc,
> my bad -- thought it would be automatic. Having that defined makes build
> fail complaining about assembly syntax in div64.S:
>
> === Cut ===
> arch/arm/lib/div64.S: Assembler messages:
> arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl
> ip)'
> arch/arm/lib/div64.S:186: Error: bad instruction `thumb( lsl r1,r1,ip)'
> arch/arm/lib/div64.S:187: Error: bad instruction `thumb( orr r2,r2,r1)'
> scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o' failed
> make[1]: *** [arch/arm/lib/div64.o] Error 1
> Makefile:1214: recipe for target 'arch/arm/lib' failed
> make: *** [arch/arm/lib] Error 2
> === Cut ===
>
> Probably something is missing in div64.h? The Linux one is totally
> different. Digging in right now...
Are you building the stuff with all of these 5+1 patches ?
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-24 19:04 ` Marek Vasut
@ 2016-03-24 19:08 ` Sergey Kubushyn
2016-03-24 19:14 ` Marek Vasut
0 siblings, 1 reply; 40+ messages in thread
From: Sergey Kubushyn @ 2016-03-24 19:08 UTC (permalink / raw)
To: u-boot
On Thu, 24 Mar 2016, Marek Vasut wrote:
> On 03/24/2016 07:43 PM, Sergey Kubushyn wrote:
>> On Thu, 24 Mar 2016, Sergey Kubushyn wrote:
>>
>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>
>>>> On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:
>>>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>>>>> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>>>>>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>>>>>>>>> On 03/24/2016 12:08 AM, Tom Rini wrote:
>>>>>>>>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn
>>>> wrote:
>>>>>>>>>> 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 > > > > > > > > <trini@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 > > > > > > > > > > <marex@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.
>>>>>>>>>>>>>> Well, this is an example of why we both don't
>>>> want libgcc ever > > > > > nor
>>>>>>>>> do we
>>>>>>>>> want to overly expand what we do offer. In this case
>>>> isn't it > > > > > an
>>>>>>>>> example of something that should be using lldiv/do_div/etc?
>>>>>>>>>>>> I haven't seen the _udivmoddi4 emitted in my tests.
>>>> Linux's libgcc > > > > copy
>>>>>>>> also doesn't implement the function. Which toolchain do you
>>>> use > > > > and
>>>>>>>> which target did you compile?
>>>>>>>>>> I'm using my own armv7hl-linux-gnueabi toolchain built
>>>> for hard > > > float.
>>>>>>> Linux
>>>>>>> arm libgcc does have arch/arm/lib/div64.S file that provides
>>>>>>> __do_div64()
>>>>>>> function that is used by do_div() from include/asm/div64.h for
>>>>>>> 32-bit
>>>>>>> ARM
>>>>>>> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_
>>>> have
>>>>>>> div64.h
>>>>>>> (that is totally different from what Linux provides) but no
>>>> div64.S > > > in
>>>>>>> arch/arm/lib.
>>>>>>>> In that case, we should just import div64.S from Linux on
>>>> arm32 and be
>>>>>> done with it ? Since we now have all the necessary macros thanks
>>>> to > > the
>>>>>> first four patches in this series, that should be trivial.
>>>>>>>> What do you think? I can bake a patch real quick, so you can
>>>> test it ?
>>>>>> Sure I'll test it, no problems. Just bake the patch :)
>>>>
>>>> Done, give it a go please.
>>>
>>> OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc. I'm
>>> analyzing it right now, will come up with more later today.
>>
>> OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private libgcc,
>> my bad -- thought it would be automatic. Having that defined makes build
>> fail complaining about assembly syntax in div64.S:
>>
>> === Cut ===
>> arch/arm/lib/div64.S: Assembler messages:
>> arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl
>> ip)'
>> arch/arm/lib/div64.S:186: Error: bad instruction `thumb( lsl r1,r1,ip)'
>> arch/arm/lib/div64.S:187: Error: bad instruction `thumb( orr r2,r2,r1)'
>> scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o' failed
>> make[1]: *** [arch/arm/lib/div64.o] Error 1
>> Makefile:1214: recipe for target 'arch/arm/lib' failed
>> make: *** [arch/arm/lib] Error 2
>> === Cut ===
>>
>> Probably something is missing in div64.h? The Linux one is totally
>> different. Digging in right now...
>
> Are you building the stuff with all of these 5+1 patches ?
Nope. Aren't those already in U-Boot master? I pulled the latest master and
thought those were there. If not would you please send me those 5 patches so
I wouldn't have to hunt them through archives?
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-24 19:08 ` Sergey Kubushyn
@ 2016-03-24 19:14 ` Marek Vasut
2016-03-24 22:25 ` Sergey Kubushyn
0 siblings, 1 reply; 40+ messages in thread
From: Marek Vasut @ 2016-03-24 19:14 UTC (permalink / raw)
To: u-boot
On 03/24/2016 08:08 PM, Sergey Kubushyn wrote:
> On Thu, 24 Mar 2016, Marek Vasut wrote:
>
>> On 03/24/2016 07:43 PM, Sergey Kubushyn wrote:
>>> On Thu, 24 Mar 2016, Sergey Kubushyn wrote:
>>>
>>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>>
>>>>> On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:
>>>>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>>>>>> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>>>>>>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>>>>>>>>>> On 03/24/2016 12:08 AM, Tom Rini wrote:
>>>>>>>>>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn
>>>>> wrote:
>>>>>>>>>>> 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 > > > > > > > > <trini@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 > > > > > > > > > > <marex@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.
>>>>>>>>>>>>>>> Well, this is an example of why we both don't
>>>>> want libgcc ever > > > > > nor
>>>>>>>>>> do we
>>>>>>>>>> want to overly expand what we do offer. In this case
>>>>> isn't it > > > > > an
>>>>>>>>>> example of something that should be using lldiv/do_div/etc?
>>>>>>>>>>>>> I haven't seen the _udivmoddi4 emitted in my tests.
>>>>> Linux's libgcc > > > > copy
>>>>>>>>> also doesn't implement the function. Which toolchain do you
>>>>> use > > > > and
>>>>>>>>> which target did you compile?
>>>>>>>>>>> I'm using my own armv7hl-linux-gnueabi toolchain built
>>>>> for hard > > > float.
>>>>>>>> Linux
>>>>>>>> arm libgcc does have arch/arm/lib/div64.S file that provides
>>>>>>>> __do_div64()
>>>>>>>> function that is used by do_div() from include/asm/div64.h for
>>>>>>>> 32-bit
>>>>>>>> ARM
>>>>>>>> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_
>>>>> have
>>>>>>>> div64.h
>>>>>>>> (that is totally different from what Linux provides) but no
>>>>> div64.S > > > in
>>>>>>>> arch/arm/lib.
>>>>>>>>> In that case, we should just import div64.S from Linux on
>>>>> arm32 and be
>>>>>>> done with it ? Since we now have all the necessary macros thanks
>>>>> to > > the
>>>>>>> first four patches in this series, that should be trivial.
>>>>>>>>> What do you think? I can bake a patch real quick, so you can
>>>>> test it ?
>>>>>>> Sure I'll test it, no problems. Just bake the patch :)
>>>>>
>>>>> Done, give it a go please.
>>>>
>>>> OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc.
>>>> I'm
>>>> analyzing it right now, will come up with more later today.
>>>
>>> OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private
>>> libgcc,
>>> my bad -- thought it would be automatic. Having that defined makes build
>>> fail complaining about assembly syntax in div64.S:
>>>
>>> === Cut ===
>>> arch/arm/lib/div64.S: Assembler messages:
>>> arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl
>>> ip)'
>>> arch/arm/lib/div64.S:186: Error: bad instruction `thumb( lsl r1,r1,ip)'
>>> arch/arm/lib/div64.S:187: Error: bad instruction `thumb( orr r2,r2,r1)'
>>> scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o'
>>> failed
>>> make[1]: *** [arch/arm/lib/div64.o] Error 1
>>> Makefile:1214: recipe for target 'arch/arm/lib' failed
>>> make: *** [arch/arm/lib] Error 2
>>> === Cut ===
>>>
>>> Probably something is missing in div64.h? The Linux one is totally
>>> different. Digging in right now...
>>
>> Are you building the stuff with all of these 5+1 patches ?
>
> Nope. Aren't those already in U-Boot master? I pulled the latest master and
> thought those were there. If not would you please send me those 5
> patches so
> I wouldn't have to hunt them through archives?
I'll send you all six off-list.
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-24 19:14 ` Marek Vasut
@ 2016-03-24 22:25 ` Sergey Kubushyn
0 siblings, 0 replies; 40+ messages in thread
From: Sergey Kubushyn @ 2016-03-24 22:25 UTC (permalink / raw)
To: u-boot
On Thu, 24 Mar 2016, Marek Vasut wrote:
> On 03/24/2016 08:08 PM, Sergey Kubushyn wrote:
>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>
>>> On 03/24/2016 07:43 PM, Sergey Kubushyn wrote:
>>>> On Thu, 24 Mar 2016, Sergey Kubushyn wrote:
>>>>
>>>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>>>
>>>>>> On 03/24/2016 12:54 AM, Sergey Kubushyn wrote:
>>>>>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>>>>>>> On 03/24/2016 12:47 AM, Sergey Kubushyn wrote:
>>>>>>>>> On Thu, 24 Mar 2016, Marek Vasut wrote:
>>>>>>>>>>>>> On 03/24/2016 12:08 AM, Tom Rini wrote:
>>>>>>>>>>> On Wed, Mar 23, 2016 at 04:02:07PM -0700, Sergey Kubushyn
>>>>>> wrote:
>>>>>>>>>>>> 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 > > > > > > > > <trini@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 > > > > > > > > > > <marex@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.
>>>>>>>>>>>>>>>> Well, this is an example of why we both don't
>>>>>> want libgcc ever > > > > > nor
>>>>>>>>>>> do we
>>>>>>>>>>> want to overly expand what we do offer. In this case
>>>>>> isn't it > > > > > an
>>>>>>>>>>> example of something that should be using lldiv/do_div/etc?
>>>>>>>>>>>>>> I haven't seen the _udivmoddi4 emitted in my tests.
>>>>>> Linux's libgcc > > > > copy
>>>>>>>>>> also doesn't implement the function. Which toolchain do you
>>>>>> use > > > > and
>>>>>>>>>> which target did you compile?
>>>>>>>>>>>> I'm using my own armv7hl-linux-gnueabi toolchain built
>>>>>> for hard > > > float.
>>>>>>>>> Linux
>>>>>>>>> arm libgcc does have arch/arm/lib/div64.S file that provides
>>>>>>>>> __do_div64()
>>>>>>>>> function that is used by do_div() from include/asm/div64.h for
>>>>>>>>> 32-bit
>>>>>>>>> ARM
>>>>>>>>> platform. Sure, arm64 has neither div64.h nor div64.S. We _DO_
>>>>>> have
>>>>>>>>> div64.h
>>>>>>>>> (that is totally different from what Linux provides) but no
>>>>>> div64.S > > > in
>>>>>>>>> arch/arm/lib.
>>>>>>>>>> In that case, we should just import div64.S from Linux on
>>>>>> arm32 and be
>>>>>>>> done with it ? Since we now have all the necessary macros thanks
>>>>>> to > > the
>>>>>>>> first four patches in this series, that should be trivial.
>>>>>>>>>> What do you think? I can bake a patch real quick, so you can
>>>>>> test it ?
>>>>>>>> Sure I'll test it, no problems. Just bake the patch :)
>>>>>>
>>>>>> Done, give it a go please.
>>>>>
>>>>> OK, it didn't work, _udivmoddi4.o is still being pulled from libgcc.
>>>>> I'm
>>>>> analyzing it right now, will come up with more later today.
>>>>
>>>> OK, it requires a CONFIG_USE_PRIVATE_LIBGCC defined to use private
>>>> libgcc,
>>>> my bad -- thought it would be automatic. Having that defined makes build
>>>> fail complaining about assembly syntax in div64.S:
>>>>
>>>> === Cut ===
>>>> arch/arm/lib/div64.S: Assembler messages:
>>>> arch/arm/lib/div64.S:185: Error: bad instruction `arm( orr r2,r2,r1,lsl
>>>> ip)'
>>>> arch/arm/lib/div64.S:186: Error: bad instruction `thumb( lsl r1,r1,ip)'
>>>> arch/arm/lib/div64.S:187: Error: bad instruction `thumb( orr r2,r2,r1)'
>>>> scripts/Makefile.build:316: recipe for target 'arch/arm/lib/div64.o'
>>>> failed
>>>> make[1]: *** [arch/arm/lib/div64.o] Error 1
>>>> Makefile:1214: recipe for target 'arch/arm/lib' failed
>>>> make: *** [arch/arm/lib] Error 2
>>>> === Cut ===
>>>>
>>>> Probably something is missing in div64.h? The Linux one is totally
>>>> different. Digging in right now...
>>>
>>> Are you building the stuff with all of these 5+1 patches ?
>>
>> Nope. Aren't those already in U-Boot master? I pulled the latest master and
>> thought those were there. If not would you please send me those 5
>> patches so
>> I wouldn't have to hunt them through archives?
>
> I'll send you all six off-list.
OK, it worked. Now it is time to push it into the official tree :)
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-24 7:50 ` Albert ARIBAUD
@ 2016-03-25 0:49 ` Tom Rini
2016-03-25 1:37 ` Sergey Kubushyn
2016-03-25 6:37 ` Albert ARIBAUD
0 siblings, 2 replies; 40+ messages in thread
From: Tom Rini @ 2016-03-25 0:49 UTC (permalink / raw)
To: u-boot
On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> Hello Tom,
>
> On Wed, 23 Mar 2016 17:36:17 -0400, Tom Rini <trini@konsulko.com> 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 <trini@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 <marex@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
>
> (ok, that explains what you mean by AEABI functions -- those are
> actually not functions defined by the AEABI, but functions that the GCC
> folks prefixed with __aeabi.)
No. For reference,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
and chapter 4 is all about the support library. We are entirely in our
right to do either of (a) use the compiler-provided library (b) provide
our own implementation of what we need. The kernel opts for (b) and I
would like us to follow that as well, consistently, rather than ad-hoc.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160324/1482e1b5/attachment.sig>
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-25 0:49 ` Tom Rini
@ 2016-03-25 1:37 ` Sergey Kubushyn
2016-03-25 6:41 ` Albert ARIBAUD
2016-03-25 6:37 ` Albert ARIBAUD
1 sibling, 1 reply; 40+ messages in thread
From: Sergey Kubushyn @ 2016-03-25 1:37 UTC (permalink / raw)
To: u-boot
On Thu, 24 Mar 2016, Tom Rini wrote:
> On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
>> Hello Tom,
>>
>> On Wed, 23 Mar 2016 17:36:17 -0400, Tom Rini <trini@konsulko.com> 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 <trini@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 <marex@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
>>
>> (ok, that explains what you mean by AEABI functions -- those are
>> actually not functions defined by the AEABI, but functions that the GCC
>> folks prefixed with __aeabi.)
>
> No. For reference,
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
> and chapter 4 is all about the support library. We are entirely in our
> right to do either of (a) use the compiler-provided library (b) provide
> our own implementation of what we need. The kernel opts for (b) and I
> would like us to follow that as well, consistently, rather than ad-hoc.
Second that. By having _EVERYTHING_ coming from U-Boot we are taking care of
_ANY_ possible mismatch between what we are building and pre-built toolchain
libraries. Soft float in ARM U-Boot and VFP hard float in most i.MX6/7
toolchains is just one of such prominent examples.
U-Boot is a standalone program not supposed to coexist with any external
applications i.e. it is totally self-sufficient, not living in some kind of
system environment so it makes perfect sense for it not to use _ANY_
external parts in the final binary.
---
******************************************************************
* KSI at home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-25 0:49 ` Tom Rini
2016-03-25 1:37 ` Sergey Kubushyn
@ 2016-03-25 6:37 ` Albert ARIBAUD
2016-03-25 6:43 ` Albert ARIBAUD
2016-03-27 13:36 ` Tom Rini
1 sibling, 2 replies; 40+ messages in thread
From: Albert ARIBAUD @ 2016-03-25 6:37 UTC (permalink / raw)
To: u-boot
Hello Tom,
On Thu, 24 Mar 2016 20:49:42 -0400, Tom Rini <trini@konsulko.com> wrote:
> On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> > Hello Tom,
> >
> > On Wed, 23 Mar 2016 17:36:17 -0400, Tom Rini <trini@konsulko.com> 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 <trini@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 <marex@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
> >
> > (ok, that explains what you mean by AEABI functions -- those are
> > actually not functions defined by the AEABI, but functions that the GCC
> > folks prefixed with __aeabi.)
>
> No. For reference,
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
> and chapter 4 is all about the support library. We are entirely in our
> right to do either of (a) use the compiler-provided library (b) provide
> our own implementation of what we need. The kernel opts for (b) and I
> would like us to follow that as well, consistently, rather than ad-hoc.
Kk, so you did not mean "whatever happens to be aeabi in libgcc, you
meant AEABI itself.
But then what you seek is is not a custom libgcc; it is controlled
AEABI support library.
I'm fine with that, since, contrary to libgcc, it has an external,
stable, definition.
But that is *unrelated* to libgcc, which is not described nor intended
as "AEABI support" -- libgcc exists in all architectures, even non-ARM,
and provides AEABI in the ARM case by accident -- or, more to the point,
by sub-optimal design IMO.
The right design for solving the problems raised by Marek is therefore
to rename U-Boot's "custom libgcc" as U-Boot's "AEABI support library"
and link U-Boot *first* against this AEABI support library, *then*
against GCC's libgcc.
Essentially, this 'hijacks' whatever is AEABI from libgcc while not
interfering with what is not AEABI (i.e. what is purely GCC/libgcc
internals).
That way,
0) U-Boot gets the stable and controlled AEABI support you want;
1) GCC keeps its somewhat stable but uncontrolled internal "generated
code / libgcc" interface;
2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc,
i.e. whatever ibgcc-related but non-AEABI-related changes occur in
a GCC release, we won't break them changes in non-AEABI ;
3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI
breakages happen in a given GCC toolchain will not break U-Boot.
4) This design works with any ARM toolchain -- which is kind of evident
since it separates generic ARM EABI support from specific toolchain
support.
Comments welcome.
> --
> Tom
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-25 1:37 ` Sergey Kubushyn
@ 2016-03-25 6:41 ` Albert ARIBAUD
0 siblings, 0 replies; 40+ messages in thread
From: Albert ARIBAUD @ 2016-03-25 6:41 UTC (permalink / raw)
To: u-boot
Hello Sergey,
On Thu, 24 Mar 2016 18:37:52 -0700 (PDT), Sergey Kubushyn
<ksi@koi8.net> wrote:
> On Thu, 24 Mar 2016, Tom Rini wrote:
> U-Boot is a standalone program not supposed to coexist with any external
> applications i.e. it is totally self-sufficient, not living in some kind of
> system environment so it makes perfect sense for it not to use _ANY_
> external parts in the final binary.
Granted U-Boot is standalone as a binary system component, but this
binary, as the produce of GCC, is dependent on libgcc for more than
simply AEABI support, hence my proposal.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-25 6:37 ` Albert ARIBAUD
@ 2016-03-25 6:43 ` Albert ARIBAUD
2016-03-27 13:36 ` Tom Rini
1 sibling, 0 replies; 40+ messages in thread
From: Albert ARIBAUD @ 2016-03-25 6:43 UTC (permalink / raw)
To: u-boot
On Fri, 25 Mar 2016 07:37:25 +0100, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Hello Tom,
> That way,
>
> 0) U-Boot gets the stable and controlled AEABI support you want;
>
> 1) GCC keeps its somewhat stable but uncontrolled internal "generated
> code / libgcc" interface;
>
> 2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc,
> i.e. whatever ibgcc-related but non-AEABI-related changes occur in
> a GCC release, we won't break them changes in non-AEABI ;
>
> 3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI
> breakages happen in a given GCC toolchain will not break U-Boot.
>
> 4) This design works with any ARM toolchain -- which is kind of evident
> since it separates generic ARM EABI support from specific toolchain
> support.
Addition: this does not mean we should get rid of the private libgcc
support: it can be useful in case of an issue with the non-aeabi part
of libgcc.
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-25 6:37 ` Albert ARIBAUD
2016-03-25 6:43 ` Albert ARIBAUD
@ 2016-03-27 13:36 ` Tom Rini
2016-03-29 9:18 ` Albert ARIBAUD
1 sibling, 1 reply; 40+ messages in thread
From: Tom Rini @ 2016-03-27 13:36 UTC (permalink / raw)
To: u-boot
On Fri, Mar 25, 2016 at 07:37:25AM +0100, Albert ARIBAUD wrote:
> Hello Tom,
>
> On Thu, 24 Mar 2016 20:49:42 -0400, Tom Rini <trini@konsulko.com> wrote:
> > On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> > > Hello Tom,
> > >
> > > On Wed, 23 Mar 2016 17:36:17 -0400, Tom Rini <trini@konsulko.com> 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 <trini@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 <marex@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
> > >
> > > (ok, that explains what you mean by AEABI functions -- those are
> > > actually not functions defined by the AEABI, but functions that the GCC
> > > folks prefixed with __aeabi.)
> >
> > No. For reference,
> > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
> > and chapter 4 is all about the support library. We are entirely in our
> > right to do either of (a) use the compiler-provided library (b) provide
> > our own implementation of what we need. The kernel opts for (b) and I
> > would like us to follow that as well, consistently, rather than ad-hoc.
>
> Kk, so you did not mean "whatever happens to be aeabi in libgcc, you
> meant AEABI itself.
>
> But then what you seek is is not a custom libgcc; it is controlled
> AEABI support library.
No. It's not libgcc. We call it libgcc, but we shouldn't. We should
call it lib1funcs which is part of the end result of Marek's patches.
LLVM has its own library which does this. But it's not about LLVM,
either.
> I'm fine with that, since, contrary to libgcc, it has an external,
> stable, definition.
>
> But that is *unrelated* to libgcc, which is not described nor intended
> as "AEABI support" -- libgcc exists in all architectures, even non-ARM,
> and provides AEABI in the ARM case by accident -- or, more to the point,
> by sub-optimal design IMO.
Yes, "libgcc" often, but not always, is how U-Boot provides the
architecture specific compiler support library functions. Or rather,
ARM and PowerPC are the big cases where we rely on -lgcc and everywhere
else simply provides the required functionality in U-Boot.
> The right design for solving the problems raised by Marek is therefore
> to rename U-Boot's "custom libgcc" as U-Boot's "AEABI support library"
> and link U-Boot *first* against this AEABI support library, *then*
> against GCC's libgcc.
>
> Essentially, this 'hijacks' whatever is AEABI from libgcc while not
> interfering with what is not AEABI (i.e. what is purely GCC/libgcc
> internals).
... but we don't need to link vs libgcc (or the compiler-dependent
helper library), ever. We can provide all of the functions we need
normally. What we need to do, and Marek's patch is fixing about half of
the problem, is always provide the required functionality so that we can
link ourself. Once we have Marek's patch in, only PowerPC is relying on
"libgcc" for some number of functions, and once that's done we can just
remove "LIBGCC" from the system.
> That way,
>
> 0) U-Boot gets the stable and controlled AEABI support you want;
To be clear, what I want is for U-Boot to not rely on having a specific
configuration of gcc available. We do not build today with various (and
correctly configured) toolchains because they are not multi-lib and we
do not allow hard float. The massive number of places that tell people
to "fix" this problem by just removing -msoft-float is very wrong. And
we aren't going to fix that problem by jumping all over stack overflow,
we're going to fix that by making it not be a problem.
> 1) GCC keeps its somewhat stable but uncontrolled internal "generated
> code / libgcc" interface;
>
> 2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc,
> i.e. whatever ibgcc-related but non-AEABI-related changes occur in
> a GCC release, we won't break them changes in non-AEABI ;
>
> 3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI
> breakages happen in a given GCC toolchain will not break U-Boot.
>
> 4) This design works with any ARM toolchain -- which is kind of evident
> since it separates generic ARM EABI support from specific toolchain
> support.
The problem here is what once we do this we are never using anything
from linking against libgcc, so there's no reason to.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160327/d0a960fa/attachment.sig>
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default
2016-03-27 13:36 ` Tom Rini
@ 2016-03-29 9:18 ` Albert ARIBAUD
0 siblings, 0 replies; 40+ messages in thread
From: Albert ARIBAUD @ 2016-03-29 9:18 UTC (permalink / raw)
To: u-boot
Hello Tom,
On Sun, 27 Mar 2016 09:36:41 -0400, Tom Rini <trini@konsulko.com> wrote:
> On Fri, Mar 25, 2016 at 07:37:25AM +0100, Albert ARIBAUD wrote:
> > Hello Tom,
> >
> > On Thu, 24 Mar 2016 20:49:42 -0400, Tom Rini <trini@konsulko.com> wrote:
> > > On Thu, Mar 24, 2016 at 08:50:03AM +0100, Albert ARIBAUD wrote:
> > > > Hello Tom,
> > > >
> > > > On Wed, 23 Mar 2016 17:36:17 -0400, Tom Rini <trini@konsulko.com> 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 <trini@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 <marex@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
> > > >
> > > > (ok, that explains what you mean by AEABI functions -- those are
> > > > actually not functions defined by the AEABI, but functions that the GCC
> > > > folks prefixed with __aeabi.)
> > >
> > > No. For reference,
> > > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf
> > > and chapter 4 is all about the support library. We are entirely in our
> > > right to do either of (a) use the compiler-provided library (b) provide
> > > our own implementation of what we need. The kernel opts for (b) and I
> > > would like us to follow that as well, consistently, rather than ad-hoc.
> >
> > Kk, so you did not mean "whatever happens to be aeabi in libgcc, you
> > meant AEABI itself.
> >
> > But then what you seek is is not a custom libgcc; it is controlled
> > AEABI support library.
>
> No. It's not libgcc. We call it libgcc, but we shouldn't. We should
> call it lib1funcs which is part of the end result of Marek's patches.
> LLVM has its own library which does this. But it's not about LLVM,
> either.
Well then, I don't know which lib the patch is about. AFAIK, libgcc is
described in https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html (which is
part of "GCC internals") as follows:
"GCC provides a low-level runtime library, libgcc.a or
libgcc_s.so.1 on some platforms. GCC generates calls to
routines in this library automatically, whenever it needs to
perform some operation that is too complicated to emit inline
code for."
To me this means that libgcc provides an interface which is private
to the GCC project, and the GCC folks can put in there whatever routine
they want if they think it helps keeping emitted code uncomplicated, an
then emit calls to this routine in the code they generate.
Do we have the same reading of this?
In that respect, LLVM is indeed no different from GCC (or any toolchain
for that matter; a compiler is not bound to emit self-sufficient code
and it is common practice to rely on a support library.
That does not change th fact that libgcc, as described above (and I
suspect that LLVM uses the same language elements to describe its own
support library) is *not* based on a standard and fixed specification,
and is *not* designed as a replaceable implementation of such a spec.
I do understand that you are unhappy with some build(s) of the GCC
toolchain where libgcc is either unfit for the intended target, or
buggy, or both. I also think AEABI support does not belong in libgcc as
it is defined in the reference above. But:
- not all builds of the same version of GCC exhibit the issue you are
raising. This should at least make us consider what it is with those
builds of GCC which exhibit the issue that makes their libgcc unfit
for a target which it is supposed to support.
- not all targets in U-Boot are affected. This should at least make us
consider that bypassing libgcc by default is not the proper approach
as it "fixes a non-bug" for many targets.
> > I'm fine with that, since, contrary to libgcc, it has an external,
> > stable, definition.
> >
> > But that is *unrelated* to libgcc, which is not described nor intended
> > as "AEABI support" -- libgcc exists in all architectures, even non-ARM,
> > and provides AEABI in the ARM case by accident -- or, more to the point,
> > by sub-optimal design IMO.
>
> Yes, "libgcc" often, but not always, is how U-Boot provides the
> architecture specific compiler support library functions. Or rather,
> ARM and PowerPC are the big cases where we rely on -lgcc and everywhere
> else simply provides the required functionality in U-Boot.
Just because some arches decided to bypass libgcc does not make it the
right design decision.
> > The right design for solving the problems raised by Marek is therefore
> > to rename U-Boot's "custom libgcc" as U-Boot's "AEABI support library"
> > and link U-Boot *first* against this AEABI support library, *then*
> > against GCC's libgcc.
> >
> > Essentially, this 'hijacks' whatever is AEABI from libgcc while not
> > interfering with what is not AEABI (i.e. what is purely GCC/libgcc
> > internals).
>
> ... but we don't need to link vs libgcc (or the compiler-dependent
> helper library), ever.
Yes we do as long as we use GCC, because we do not know what calls GCC
might emit to some routine it provides in the corresponding libgcc.
This interface between GCC-emitted code is not public. It is not
controlled by us. It is controlled by GCC and by hijacking all of
libgcc, we break this interface and force GCC to fail, but that's not a
shortcoming of GCC, it is a shortcoming of us.
> We can provide all of the functions we need
> normally.
Again, this is not about functions we need. This is about fonctions the
GCC project decides it needs, and decides to generate calls to in code
emitted by their compiler and provide and implementation in their
libgcc.
> What we need to do, and Marek's patch is fixing about half of
> the problem, is always provide the required functionality so that we can
> link ourself.
Yes, and for the routines that GCC emits calls to in the course of
compiling our code, the corresponding functionality is provided by
GCC's libgcc.
If we need something because GCC-emitted code calls it, then libgcc
provides it.
If we need something because GCC-emitted code calls it but which our
toolchain of choice does not provide in its libgcc, then it's a GCC or
toolchain build issue, and I'm fine with overriding *that* thing with a
custom libgcc -- which we can do without entirely bypassing the
toolchain's own libgcc.
Last, if we need something which is not called by GCC-emitted code but
explicitly by us, then we should provide that thing, but then there is
no reason to put it in libgcc since that thing is no a way for the
compiler to avoid emiggint inline code -- which is all what libgcc is about.
> Once we have Marek's patch in, only PowerPC is relying on
> "libgcc" for some number of functions, and once that's done we can just
> remove "LIBGCC" from the system.
Or, with Marek's patch redesigned, we can keep using GCC in a proper
way *and* fix exactly what needs to be fixed, for targets that need it
fixed, without interfering with a third party tool's internal
interfaces.
> > That way,
> >
> > 0) U-Boot gets the stable and controlled AEABI support you want;
>
> To be clear, what I want is for U-Boot to not rely on having a specific
> configuration of gcc available.
If by this you mean you do not want U-Boot not to rely on a given GCC
build's defaults such as default endianness, default CPU, default arch,
etc, I'm 100% with you. If you mean you want to use any ARM GCC build
for any ARM target regardless of whether that build actually has
support for it, then I would disagree.
As a simple example: if your ARM GCC build has compiler support for big-
and little-endian, but only provides libgcc for little-endian, then I
expect that GCC build to succeed in building all little-endian U-Boot
ARM targets, but I don't expect it to build big-endian ones, since as a
toolchain, it does not support big-endian.
> We do not build today with various (and
> correctly configured) toolchains because they are not multi-lib and we
> do not allow hard float.
So what you mean is that you're using a toolchain which only supports
hard float and want to build non-hard float targets. You're using a
tool which is not suited to your needs.
> The massive number of places that tell people
> to "fix" this problem by just removing -msoft-float is very wrong.
Agreed.
> And
> we aren't going to fix that problem by jumping all over stack overflow,
> we're going to fix that by making it not be a problem.
Indeed, but the solution is not to let people use inadequate
toolchains. We don't hesitate to tell people not to use too old a
U-Boot version; we don't hesitate to tell people not to use too old a
GCC version; why hesitate in telling them not to use too inadequate a
GCC version? All the more when a simple buildman command wll provide
them with a working one.
> > 1) GCC keeps its somewhat stable but uncontrolled internal "generated
> > code / libgcc" interface;
> >
> > 2) U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc,
> > i.e. whatever ibgcc-related but non-AEABI-related changes occur in
> > a GCC release, we won't break them changes in non-AEABI ;
> >
> > 3) GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI
> > breakages happen in a given GCC toolchain will not break U-Boot.
> >
> > 4) This design works with any ARM toolchain -- which is kind of evident
> > since it separates generic ARM EABI support from specific toolchain
> > support.
>
> The problem here is what once we do this we are never using anything
> from linking against libgcc, so there's no reason to.
That's only if you follow this proposal *and* insist on *still*
replacing GCC'slibgcc entirely with our custom libgcc by default (and
still assume GCC will never ever change anything to its libgcc, too).
My proposal assumes custom libgcc is only used to fix bugs in libgcc
(for those versions of GCC that exhibit such bugs) or to support GCC
builds when no other GCC toolchain build exists that can build a given
target. No bugs and there is an easily accessible GCC build for the
target? No need for private libgcc.
(also, custom libgcc should not *replace* libgcc. It should replace
*those symbols* in libgcc which require replacing -- the same way
that we don't entirely replace libc just because we have better
versions of memmove/memcpy/memset.)
> --
> Tom
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 2/5] arm: lib: Drop underscore from private libgcc filenames
2016-03-20 16:15 ` [U-Boot] [PATCH 2/5] arm: lib: Drop underscore from private libgcc filenames Marek Vasut
@ 2016-04-09 18:34 ` Simon Glass
0 siblings, 0 replies; 40+ messages in thread
From: Simon Glass @ 2016-04-09 18:34 UTC (permalink / raw)
To: u-boot
On 20 March 2016 at 10:15, Marek Vasut <marex@denx.de> wrote:
> Drop the underscore from the filenames of files implementing libgcc
> routines. There is no functional change. This change is done to make
> sync with Linux kernel easier.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tom Rini <trini@konsulko.com>
> ---
> arch/arm/lib/Makefile | 6 +++---
> arch/arm/lib/{_ashldi3.S => ashldi3.S} | 0
> arch/arm/lib/{_ashrdi3.S => ashrdi3.S} | 0
> arch/arm/lib/{_divsi3.S => divsi3.S} | 0
> arch/arm/lib/{_lshrdi3.S => lshrdi3.S} | 0
> arch/arm/lib/{_modsi3.S => modsi3.S} | 0
> arch/arm/lib/{_udivsi3.S => udivsi3.S} | 0
> arch/arm/lib/{_uldivmod.S => uldivmod.S} | 0
> arch/arm/lib/{_umodsi3.S => umodsi3.S} | 0
> 9 files changed, 3 insertions(+), 3 deletions(-)
> rename arch/arm/lib/{_ashldi3.S => ashldi3.S} (100%)
> rename arch/arm/lib/{_ashrdi3.S => ashrdi3.S} (100%)
> rename arch/arm/lib/{_divsi3.S => divsi3.S} (100%)
> rename arch/arm/lib/{_lshrdi3.S => lshrdi3.S} (100%)
> rename arch/arm/lib/{_modsi3.S => modsi3.S} (100%)
> rename arch/arm/lib/{_udivsi3.S => udivsi3.S} (100%)
> rename arch/arm/lib/{_uldivmod.S => uldivmod.S} (100%)
> rename arch/arm/lib/{_umodsi3.S => umodsi3.S} (100%)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel
2016-03-20 16:15 [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel Marek Vasut
` (3 preceding siblings ...)
2016-03-20 16:15 ` [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default Marek Vasut
@ 2016-04-09 18:34 ` Simon Glass
2016-04-28 0:28 ` Marek Vasut
4 siblings, 1 reply; 40+ messages in thread
From: Simon Glass @ 2016-04-09 18:34 UTC (permalink / raw)
To: u-boot
Hi Marek,
On 20 March 2016 at 10:15, Marek Vasut <marex@denx.de> wrote:
> Import unified.h from Linux kernel 4.4.6 , commit
> 0d1912303e54ed1b2a371be0bba51c384dd57326 . This header file contains
> macros used in libgcc functions in Linux kernel on ARM and will be
> needed for the libgcc sync.
>
> Since unified.h defines the W(instr) macro, we must drop this from
> the macro from memcpy.S , otherwise this triggers a warning about
> symbol redefinition. In order to keep the changes to unified.h to
> the minimum, tweak arch/arm/lib/Makefile such that it defines new
> CONFIG_THUMB2_KERNEL macro, which is already checked by unified.h,
> only if Thumb build is enabled, but the target does not support
> Thumb2 . This way we can remove ad-hoc -DMEMSET_NO_THUMB_BUILD and
> -DMEMCPY_NO_THUMB_BUILD and we do not change the logic.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tom Rini <trini@konsulko.com>
> ---
> arch/arm/include/asm/assembler.h | 1 +
> arch/arm/include/asm/unified.h | 140 +++++++++++++++++++++++++++++++++++++++
> arch/arm/lib/Makefile | 6 +-
> arch/arm/lib/memcpy.S | 6 --
> 4 files changed, 144 insertions(+), 9 deletions(-)
> create mode 100644 arch/arm/include/asm/unified.h
Reviewed-by: Simon Glass <sjg@chromium.org>
Can we use SPDX?
>
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 11b80fb..ae1e42f 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -15,6 +15,7 @@
> */
>
> #include <config.h>
> +#include <asm/unified.h>
>
> /*
> * Endian independent macros for shifting bytes within registers.
> diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
> new file mode 100644
> index 0000000..a91ae49
> --- /dev/null
> +++ b/arch/arm/include/asm/unified.h
> @@ -0,0 +1,140 @@
> +/*
> + * include/asm-arm/unified.h - Unified Assembler Syntax helper macros
> + *
> + * Copyright (C) 2008 ARM Limited
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +
> +#ifndef __ASM_UNIFIED_H
> +#define __ASM_UNIFIED_H
> +
> +#if defined(__ASSEMBLY__) && defined(CONFIG_ARM_ASM_UNIFIED)
> + .syntax unified
> +#endif
> +
> +#ifdef CONFIG_CPU_V7M
> +#define AR_CLASS(x...)
> +#define M_CLASS(x...) x
> +#else
> +#define AR_CLASS(x...) x
> +#define M_CLASS(x...)
> +#endif
> +
> +#ifdef CONFIG_THUMB2_KERNEL
> +
> +#if __GNUC__ < 4
> +#error Thumb-2 kernel requires gcc >= 4
> +#endif
> +
> +/* The CPSR bit describing the instruction set (Thumb) */
> +#define PSR_ISETSTATE PSR_T_BIT
> +
> +#define ARM(x...)
> +#define THUMB(x...) x
> +#ifdef __ASSEMBLY__
> +#define W(instr) instr.w
> +#else
> +#define WASM(instr) #instr ".w"
> +#endif
> +
> +#else /* !CONFIG_THUMB2_KERNEL */
> +
> +/* The CPSR bit describing the instruction set (ARM) */
> +#define PSR_ISETSTATE 0
> +
> +#define ARM(x...) x
> +#define THUMB(x...)
> +#ifdef __ASSEMBLY__
> +#define W(instr) instr
> +#else
> +#define WASM(instr) #instr
> +#endif
> +
> +#endif /* CONFIG_THUMB2_KERNEL */
> +
> +#ifndef CONFIG_ARM_ASM_UNIFIED
> +
> +/*
> + * If the unified assembly syntax isn't used (in ARM mode), these
> + * macros expand to an empty string
> + */
> +#ifdef __ASSEMBLY__
> + .macro it, cond
> + .endm
> + .macro itt, cond
> + .endm
> + .macro ite, cond
> + .endm
> + .macro ittt, cond
> + .endm
> + .macro itte, cond
> + .endm
> + .macro itet, cond
> + .endm
> + .macro itee, cond
> + .endm
> + .macro itttt, cond
> + .endm
> + .macro ittte, cond
> + .endm
> + .macro ittet, cond
> + .endm
> + .macro ittee, cond
> + .endm
> + .macro itett, cond
> + .endm
> + .macro itete, cond
> + .endm
> + .macro iteet, cond
> + .endm
> + .macro iteee, cond
> + .endm
> +#else /* !__ASSEMBLY__ */
> +__asm__(
> +" .macro it, cond\n"
> +" .endm\n"
> +" .macro itt, cond\n"
> +" .endm\n"
> +" .macro ite, cond\n"
> +" .endm\n"
> +" .macro ittt, cond\n"
> +" .endm\n"
> +" .macro itte, cond\n"
> +" .endm\n"
> +" .macro itet, cond\n"
> +" .endm\n"
> +" .macro itee, cond\n"
> +" .endm\n"
> +" .macro itttt, cond\n"
> +" .endm\n"
> +" .macro ittte, cond\n"
> +" .endm\n"
> +" .macro ittet, cond\n"
> +" .endm\n"
> +" .macro ittee, cond\n"
> +" .endm\n"
> +" .macro itett, cond\n"
> +" .endm\n"
> +" .macro itete, cond\n"
> +" .endm\n"
> +" .macro iteet, cond\n"
> +" .endm\n"
> +" .macro iteee, cond\n"
> +" .endm\n");
> +#endif /* __ASSEMBLY__ */
> +
> +#endif /* CONFIG_ARM_ASM_UNIFIED */
> +
> +#endif /* !__ASM_UNIFIED_H */
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index 7a0fb58..a930744 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -80,8 +80,8 @@ CFLAGS_cache-cp15.o := -marm
>
> AFLAGS_REMOVE_memset.o := -mthumb -mthumb-interwork
> AFLAGS_REMOVE_memcpy.o := -mthumb -mthumb-interwork
> -AFLAGS_memset.o := -DMEMSET_NO_THUMB_BUILD
> -AFLAGS_memcpy.o := -DMEMCPY_NO_THUMB_BUILD
> -
> +else
> +AFLAGS_memset.o := -DCONFIG_THUMB2_KERNEL
> +AFLAGS_memcpy.o := -DCONFIG_THUMB2_KERNEL
> endif
> endif
> diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
> index 7d9fc0f..00602e9 100644
> --- a/arch/arm/lib/memcpy.S
> +++ b/arch/arm/lib/memcpy.S
> @@ -13,12 +13,6 @@
> #include <linux/linkage.h>
> #include <asm/assembler.h>
>
> -#if defined(CONFIG_SYS_THUMB_BUILD) && !defined(MEMCPY_NO_THUMB_BUILD)
> -#define W(instr) instr.w
> -#else
> -#define W(instr) instr
> -#endif
> -
> #define LDR1W_SHIFT 0
> #define STR1W_SHIFT 0
>
> --
> 2.7.0
>
Regards,
Simon
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 3/5] arm: lib: Sync libgcc shift operations
2016-03-20 16:15 ` [U-Boot] [PATCH 3/5] arm: lib: Sync libgcc shift operations Marek Vasut
@ 2016-04-09 18:34 ` Simon Glass
0 siblings, 0 replies; 40+ messages in thread
From: Simon Glass @ 2016-04-09 18:34 UTC (permalink / raw)
To: u-boot
On 20 March 2016 at 10:15, Marek Vasut <marex@denx.de> wrote:
> Sync the libgcc shift operations with Linux kernel 4.4.6 , commit
> 0d1912303e54ed1b2a371be0bba51c384dd57326 . Syncing these three
> files is easy, as there is almost no change in them, except the
> addition of Thumb support.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tom Rini <trini@konsulko.com>
> ---
> arch/arm/lib/ashldi3.S | 12 ++++++++----
> arch/arm/lib/ashrdi3.S | 12 ++++++++----
> arch/arm/lib/lshrdi3.S | 12 ++++++++----
> 3 files changed, 24 insertions(+), 12 deletions(-)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 4/5] arm: lib: Sync libgcc 32b division/modulo operations
2016-03-20 16:15 ` [U-Boot] [PATCH 4/5] arm: lib: Sync libgcc 32b division/modulo operations Marek Vasut
@ 2016-04-09 18:34 ` Simon Glass
0 siblings, 0 replies; 40+ messages in thread
From: Simon Glass @ 2016-04-09 18:34 UTC (permalink / raw)
To: u-boot
On 20 March 2016 at 10:15, Marek Vasut <marex@denx.de> wrote:
> Sync the libgcc 32bit division and modulo operations with Linux 4.4.6 ,
> commit 0d1912303e54ed1b2a371be0bba51c384dd57326 . The functions in these
> four files are present in lib1funcs.S in Linux, so replace these files
> with lib1funcs.S from Linux.
>
> Since we do not support stack unwinding, instead of importing the whole
> asm/unwind.h and all the baggage, this patch defines empty UNWIND() macro
> in lib1funcs.S . Moreover, to make all of the functions available, define
> CONFIG_AEABI , which is safe, because U-Boot is always compiled with ARM
> EABI.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tom Rini <trini@konsulko.com>
> ---
> arch/arm/lib/Makefile | 5 +-
> arch/arm/lib/divsi3.S | 143 -------------------
> arch/arm/lib/lib1funcs.S | 351 +++++++++++++++++++++++++++++++++++++++++++++++
> arch/arm/lib/modsi3.S | 99 -------------
> arch/arm/lib/udivsi3.S | 95 -------------
> arch/arm/lib/umodsi3.S | 90 ------------
> 6 files changed, 353 insertions(+), 430 deletions(-)
> delete mode 100644 arch/arm/lib/divsi3.S
> create mode 100644 arch/arm/lib/lib1funcs.S
> delete mode 100644 arch/arm/lib/modsi3.S
> delete mode 100644 arch/arm/lib/udivsi3.S
> delete mode 100644 arch/arm/lib/umodsi3.S
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 40+ messages in thread
* [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel
2016-04-09 18:34 ` [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel Simon Glass
@ 2016-04-28 0:28 ` Marek Vasut
0 siblings, 0 replies; 40+ messages in thread
From: Marek Vasut @ 2016-04-28 0:28 UTC (permalink / raw)
To: u-boot
On 04/09/2016 08:34 PM, Simon Glass wrote:
> Hi Marek,
>
> On 20 March 2016 at 10:15, Marek Vasut <marex@denx.de> wrote:
>> Import unified.h from Linux kernel 4.4.6 , commit
>> 0d1912303e54ed1b2a371be0bba51c384dd57326 . This header file contains
>> macros used in libgcc functions in Linux kernel on ARM and will be
>> needed for the libgcc sync.
>>
>> Since unified.h defines the W(instr) macro, we must drop this from
>> the macro from memcpy.S , otherwise this triggers a warning about
>> symbol redefinition. In order to keep the changes to unified.h to
>> the minimum, tweak arch/arm/lib/Makefile such that it defines new
>> CONFIG_THUMB2_KERNEL macro, which is already checked by unified.h,
>> only if Thumb build is enabled, but the target does not support
>> Thumb2 . This way we can remove ad-hoc -DMEMSET_NO_THUMB_BUILD and
>> -DMEMCPY_NO_THUMB_BUILD and we do not change the logic.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
>> Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
>> Cc: Simon Glass <sjg@chromium.org>
>> Cc: Tom Rini <trini@konsulko.com>
>> ---
>> arch/arm/include/asm/assembler.h | 1 +
>> arch/arm/include/asm/unified.h | 140 +++++++++++++++++++++++++++++++++++++++
>> arch/arm/lib/Makefile | 6 +-
>> arch/arm/lib/memcpy.S | 6 --
>> 4 files changed, 144 insertions(+), 9 deletions(-)
>> create mode 100644 arch/arm/include/asm/unified.h
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> Can we use SPDX?
Yes, done. Thanks!
Best regards,
Marek Vasut
^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2016-04-28 0:28 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-20 16:15 [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel Marek Vasut
2016-03-20 16:15 ` [U-Boot] [PATCH 2/5] arm: lib: Drop underscore from private libgcc filenames Marek Vasut
2016-04-09 18:34 ` Simon Glass
2016-03-20 16:15 ` [U-Boot] [PATCH 3/5] arm: lib: Sync libgcc shift operations Marek Vasut
2016-04-09 18:34 ` Simon Glass
2016-03-20 16:15 ` [U-Boot] [PATCH 4/5] arm: lib: Sync libgcc 32b division/modulo operations Marek Vasut
2016-04-09 18:34 ` Simon Glass
2016-03-20 16:15 ` [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default Marek Vasut
2016-03-23 12:53 ` Albert ARIBAUD
2016-03-23 13:22 ` Tom Rini
2016-03-23 17:08 ` Albert ARIBAUD
2016-03-23 21:36 ` Tom Rini
2016-03-23 23:02 ` Sergey Kubushyn
2016-03-23 23:08 ` Tom Rini
2016-03-23 23:24 ` Sergey Kubushyn
2016-03-23 23:24 ` Marek Vasut
2016-03-23 23:47 ` Sergey Kubushyn
2016-03-23 23:49 ` Marek Vasut
2016-03-23 23:54 ` Sergey Kubushyn
2016-03-24 0:10 ` [U-Boot] [PATCH] arm: lib: Import __do_div64 from Linux Marek Vasut
2016-03-24 0:11 ` [U-Boot] [PATCH 5/5] lib: Enable private libgcc by default Marek Vasut
2016-03-24 2:28 ` Sergey Kubushyn
2016-03-24 18:18 ` Sergey Kubushyn
2016-03-24 18:43 ` Sergey Kubushyn
2016-03-24 19:04 ` Marek Vasut
2016-03-24 19:08 ` Sergey Kubushyn
2016-03-24 19:14 ` Marek Vasut
2016-03-24 22:25 ` Sergey Kubushyn
2016-03-24 0:13 ` Tom Rini
2016-03-24 0:36 ` Marek Vasut
2016-03-24 7:50 ` Albert ARIBAUD
2016-03-25 0:49 ` Tom Rini
2016-03-25 1:37 ` Sergey Kubushyn
2016-03-25 6:41 ` Albert ARIBAUD
2016-03-25 6:37 ` Albert ARIBAUD
2016-03-25 6:43 ` Albert ARIBAUD
2016-03-27 13:36 ` Tom Rini
2016-03-29 9:18 ` Albert ARIBAUD
2016-04-09 18:34 ` [U-Boot] [PATCH 1/5] arm: include: Import unified.h from Linux kernel Simon Glass
2016-04-28 0:28 ` Marek Vasut
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.