Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1455443 > unrolled thread
| Started by | "Luis R. Rodriguez" <mcgrof@kernel.org> |
|---|---|
| First post | 2016-08-02 22:10 +0200 |
| Last post | 2016-08-03 05:30 +0200 |
| Articles | 11 on this page of 31 — 7 participants |
Back to article view | Back to linux.kernel
powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-02 22:10 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Guenter Roeck <linux@roeck-us.net> - 2016-08-03 00:00 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures "Luis R. Rodriguez" <mcgrof@kernel.org> - 2016-08-03 00:30 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-03 00:50 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Stephen Rothwell <sfr@canb.auug.org.au> - 2016-08-03 02:30 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-03 10:00 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Stephen Rothwell <sfr@canb.auug.org.au> - 2016-08-03 14:30 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-03 14:40 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Nicholas Piggin <npiggin@gmail.com> - 2016-08-03 18:00 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-03 21:10 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-03 22:20 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Segher Boessenkool <segher@kernel.crashing.org> - 2016-08-03 22:50 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Stephen Rothwell <sfr@canb.auug.org.au> - 2016-08-04 02:20 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-04 11:10 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-04 12:50 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Nicholas Piggin <npiggin@gmail.com> - 2016-08-04 13:50 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-04 14:20 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Nicholas Piggin <npiggin@gmail.com> - 2016-08-04 14:40 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-04 17:50 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Nicholas Piggin <npiggin@gmail.com> - 2016-08-04 18:10 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-04 18:20 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Segher Boessenkool <segher@kernel.crashing.org> - 2016-08-04 20:30 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Nicholas Piggin <npiggin@gmail.com> - 2016-08-05 10:50 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-05 12:20 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Nicholas Piggin <npiggin@gmail.com> - 2016-08-05 14:30 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-05 18:10 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Nicholas Piggin <npiggin@gmail.com> - 2016-08-05 18:20 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-05 21:20 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Nicholas Piggin <npiggin@gmail.com> - 2016-08-06 22:50 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-06 23:20 +0200
Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Michael Ellerman <mpe@ellerman.id.au> - 2016-08-03 05:30 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-08-04 18:20 +0200 |
| Subject | Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures |
| Message-ID | <s2txg-3gC-5@gated-at.bofh.it> |
| In reply to | #1456361 |
On Thursday, August 4, 2016 9:47:13 PM CEST Nicholas Piggin wrote:
> + __used \
> + __attribute__((section("___kentry" "+" #sym ",\"a\",@note #"), used)) \
I've just started testing this, but the first problem I ran into
is that @ and # are special characters that have an architecture
specific meaning to the assembler. On ARM, you need "%note @" instead
of "@note #".
Arnd
[toc] | [prev] | [next] | [standalone]
| From | Segher Boessenkool <segher@kernel.crashing.org> |
|---|---|
| Date | 2016-08-04 20:30 +0200 |
| Subject | Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures |
| Message-ID | <s2vz3-4Ek-3@gated-at.bofh.it> |
| In reply to | #1456523 |
On Thu, Aug 04, 2016 at 06:10:57PM +0200, Arnd Bergmann wrote:
> On Thursday, August 4, 2016 9:47:13 PM CEST Nicholas Piggin wrote:
>
> > + __used \
> > + __attribute__((section("___kentry" "+" #sym ",\"a\",@note #"), used)) \
>
>
> I've just started testing this, but the first problem I ran into
> is that @ and # are special characters that have an architecture
> specific meaning to the assembler. On ARM, you need "%note @" instead
> of "@note #".
That comment trick (I still feel guilty about it) causes more problems
than it solves. Please don't try to use it :-)
Segher
[toc] | [prev] | [next] | [standalone]
| From | Nicholas Piggin <npiggin@gmail.com> |
|---|---|
| Date | 2016-08-05 10:50 +0200 |
| Message-ID | <s2IZj-59m-1@gated-at.bofh.it> |
| In reply to | #1456623 |
On Thu, 4 Aug 2016 12:06:41 -0500
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> On Thu, Aug 04, 2016 at 06:10:57PM +0200, Arnd Bergmann wrote:
> > On Thursday, August 4, 2016 9:47:13 PM CEST Nicholas Piggin wrote:
> >
> > > + __used \
> > > + __attribute__((section("___kentry" "+" #sym ",\"a\",@note #"), used)) \
> >
> >
> > I've just started testing this, but the first problem I ran into
> > is that @ and # are special characters that have an architecture
> > specific meaning to the assembler. On ARM, you need "%note @" instead
> > of "@note #".
>
> That comment trick (I still feel guilty about it) causes more problems
> than it solves. Please don't try to use it :-)
Yeah that's a funny hack. I don't think it's required though, but I'm just
running through some more tests.
I think I found an improvement with the thin archives as well -- we were
still building symbol table after removing the s option (that only avoids
index). "S" is required to not build symbol table.
I'll send out an RFC on a slightly more polished patch series shortly.
Thanks,
Nick
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-08-05 12:20 +0200 |
| Subject | Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures |
| Message-ID | <s2Koq-69A-7@gated-at.bofh.it> |
| In reply to | #1456951 |
On Friday, August 5, 2016 6:41:08 PM CEST Nicholas Piggin wrote:
> On Thu, 4 Aug 2016 12:06:41 -0500
> Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
> > On Thu, Aug 04, 2016 at 06:10:57PM +0200, Arnd Bergmann wrote:
> > > On Thursday, August 4, 2016 9:47:13 PM CEST Nicholas Piggin wrote:
> > >
> > > > + __used \
> > > > + __attribute__((section("___kentry" "+" #sym ",\"a\",@note #"), used)) \
> > >
> > >
> > > I've just started testing this, but the first problem I ran into
> > > is that @ and # are special characters that have an architecture
> > > specific meaning to the assembler. On ARM, you need "%note @" instead
> > > of "@note #".
> >
> > That comment trick (I still feel guilty about it) causes more problems
> > than it solves. Please don't try to use it :-)
>
> Yeah that's a funny hack. I don't think it's required though, but I'm just
> running through some more tests.
>
> I think I found an improvement with the thin archives as well -- we were
> still building symbol table after removing the s option (that only avoids
> index). "S" is required to not build symbol table.
>
> I'll send out an RFC on a slightly more polished patch series shortly.
I could not find Nico's patches, but based on the information in his
presentation at
https://www.linuxplumbersconf.org/2015/ocw//system/presentations/3369/original/slides.html#(1)
I created a patch for ARM that mirrors what you have for powerpc, see
below.
I have successfully built normal-sized kernels with this (not tried
running them). Unfortunately, the build time for "allyesconfig"
kernel explodes, the final link time is now in the hours instead of
minutes (no exact numbers unfortunately, it takes too long to
reproduce), and I also get link errors for the .text.fixup section
for any users of __put_user() in really large kernels:
net/batman-adv/batman-adv.o:(.text.fixup+0x4): relocation truncated to fit: R_ARM_JUMP24 against `.text.batadv_log_read'
...
drivers/scsi/sg.o:(.text.fixup+0x4): relocation truncated to fit: R_ARM_THM_JUMP24 against `.text.sg_ioctl'
drivers/scsi/sg.o:(.text.fixup+0xc): relocation truncated to fit: R_ARM_THM_JUMP24 against `.text.sg_ioctl'
drivers/scsi/sg.o:(.text.fixup+0x14): relocation truncated to fit: R_ARM_THM_JUMP24 against `.text.sg_ioctl'
...
This originates from
#define __put_user_asm(x, __pu_addr, err, instr) \
__asm__ __volatile__( \
"1: " TUSER(instr) " %1, [%2], #0\n" \
"2:\n" \
" .pushsection .text.fixup,\"ax\"\n" \
" .align 2\n" \
"3: mov %0, %3\n" \
" b 2b\n" \
" .popsection\n" \
" .pushsection __ex_table,\"a\"\n" \
" .align 3\n" \
" .long 1b, 3b\n" \
" .popsection" \
: "+r" (err) \
: "r" (x), "r" (__pu_addr), "i" (-EFAULT) \
: "cc")
Arnd
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 842f46af5b9d..b4fc91603429 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -362,6 +362,8 @@ archclean:
# My testing targets (bypasses dependencies)
bp:; $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/bootpImage
+KBUILD_CFLAGS += -ffunction-sections -fdata-sections
+LDFLAGS_vmlinux += --gc-sections
define archhelp
echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index ad325a8c7e1e..f0eca9a96005 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -11,6 +11,9 @@ CFLAGS_REMOVE_insn.o = -pg
CFLAGS_REMOVE_patch.o = -pg
endif
+ccflags-y += -fno-function-sections -fno-data-sections
+subdir-ccflags-y += -fno-function-sections -fno-data-sections
+
CFLAGS_REMOVE_return_address.o = -pg
# Object file lists.
diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
index 56c8bdf776bd..ef7d8d7a997b 100644
--- a/arch/arm/kernel/vmlinux-xip.lds.S
+++ b/arch/arm/kernel/vmlinux-xip.lds.S
@@ -12,17 +12,17 @@
#define PROC_INFO \
. = ALIGN(4); \
VMLINUX_SYMBOL(__proc_info_begin) = .; \
- *(.proc.info.init) \
+ KEEP(*(.proc.info.init)) \
VMLINUX_SYMBOL(__proc_info_end) = .;
#define IDMAP_TEXT \
ALIGN_FUNCTION(); \
VMLINUX_SYMBOL(__idmap_text_start) = .; \
- *(.idmap.text) \
+ KEEP(*(.idmap.text)) \
VMLINUX_SYMBOL(__idmap_text_end) = .; \
. = ALIGN(PAGE_SIZE); \
VMLINUX_SYMBOL(__hyp_idmap_text_start) = .; \
- *(.hyp.idmap.text) \
+ KEEP(*(.hyp.idmap.text)) \
VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
#ifdef CONFIG_HOTPLUG_CPU
@@ -93,7 +93,7 @@ SECTIONS
_stext = .; /* Text and read-only data */
IDMAP_TEXT
__exception_text_start = .;
- *(.exception.text)
+ KEEP(*(.exception.text))
__exception_text_end = .;
IRQENTRY_TEXT
TEXT_TEXT
@@ -114,11 +114,11 @@ SECTIONS
__ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
__start___ex_table = .;
#ifdef CONFIG_MMU
- *(__ex_table)
+ KEEP(*(__ex_table))
#endif
__stop___ex_table = .;
}
-
+)
#ifdef CONFIG_ARM_UNWIND
/*
* Stack unwinding tables
@@ -126,12 +126,12 @@ SECTIONS
. = ALIGN(8);
.ARM.unwind_idx : {
__start_unwind_idx = .;
- *(.ARM.exidx*)
+ KEEP(*(.ARM.exidx*))
__stop_unwind_idx = .;
}
.ARM.unwind_tab : {
__start_unwind_tab = .;
- *(.ARM.extab*)
+ KEEP(*(.ARM.extab*))
__stop_unwind_tab = .;
}
#endif
@@ -146,14 +146,14 @@ SECTIONS
*/
__vectors_start = .;
.vectors 0xffff0000 : AT(__vectors_start) {
- *(.vectors)
+ KEEP(*(.vectors))
}
. = __vectors_start + SIZEOF(.vectors);
__vectors_end = .;
__stubs_start = .;
.stubs ADDR(.vectors) + 0x1000 : AT(__stubs_start) {
- *(.stubs)
+ KEEP(*(.stubs))
}
. = __stubs_start + SIZEOF(.stubs);
__stubs_end = .;
@@ -169,24 +169,24 @@ SECTIONS
}
.init.arch.info : {
__arch_info_begin = .;
- *(.arch.info.init)
+ KEEP(*(.arch.info.init))
__arch_info_end = .;
}
.init.tagtable : {
__tagtable_begin = .;
- *(.taglist.init)
+ KEEP(*(.taglist.init))
__tagtable_end = .;
}
#ifdef CONFIG_SMP_ON_UP
.init.smpalt : {
__smpalt_begin = .;
- *(.alt.smp.init)
+ KEEP(*(.alt.smp.init))
__smpalt_end = .;
}
#endif
.init.pv_table : {
__pv_table_begin = .;
- *(.pv_table)
+ KEEP(*(.pv_table))
__pv_table_end = .;
}
.init.data : {
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 7396a5f00c5f..61b9b8784036 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -17,7 +17,7 @@
#define PROC_INFO \
. = ALIGN(4); \
VMLINUX_SYMBOL(__proc_info_begin) = .; \
- *(.proc.info.init) \
+ KEEP(*(.proc.info.init)) \
VMLINUX_SYMBOL(__proc_info_end) = .;
#define HYPERVISOR_TEXT \
@@ -104,7 +104,7 @@ SECTIONS
_stext = .; /* Text and read-only data */
IDMAP_TEXT
__exception_text_start = .;
- *(.exception.text)
+ KEEP(*(.exception.text))
__exception_text_end = .;
IRQENTRY_TEXT
SOFTIRQENTRY_TEXT
@@ -169,14 +169,14 @@ SECTIONS
*/
__vectors_start = .;
.vectors 0xffff0000 : AT(__vectors_start) {
- *(.vectors)
+ KEEP(*(.vectors))
}
. = __vectors_start + SIZEOF(.vectors);
__vectors_end = .;
__stubs_start = .;
.stubs ADDR(.vectors) + 0x1000 : AT(__stubs_start) {
- *(.stubs)
+ KEEP(*(.stubs))
}
. = __stubs_start + SIZEOF(.stubs);
__stubs_end = .;
@@ -192,24 +192,24 @@ SECTIONS
}
.init.arch.info : {
__arch_info_begin = .;
- *(.arch.info.init)
+ KEEP(*(.arch.info.init))
__arch_info_end = .;
}
.init.tagtable : {
__tagtable_begin = .;
- *(.taglist.init)
+ KEEP(*(.taglist.init))
__tagtable_end = .;
}
#ifdef CONFIG_SMP_ON_UP
.init.smpalt : {
__smpalt_begin = .;
- *(.alt.smp.init)
+ KEEP(*(.alt.smp.init))
__smpalt_end = .;
}
#endif
.init.pv_table : {
__pv_table_begin = .;
- *(.pv_table)
+ KEEP(*(.pv_table))
__pv_table_end = .;
}
.init.data : {
diff --git a/include/linux/export.h b/include/linux/export.h
index cc65d53792c0..f2b7714238f3 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -46,7 +46,7 @@ extern struct module __this_module;
extern __visible void *__crc_##sym __attribute__((weak)); \
static const unsigned long __kcrctab_##sym \
__used \
- __attribute__((section("___kcrctab" sec "+" #sym ",\"a\",@note #"), used)) \
+ __attribute__((section("___kcrctab" sec "+" #sym ",\"a\",%note @"), used)) \
= (unsigned long) &__crc_##sym;
#else
#define __CRC_SYMBOL(sym, sec)
@@ -57,12 +57,12 @@ extern struct module __this_module;
extern typeof(sym) sym; \
__CRC_SYMBOL(sym, sec) \
static const char __kstrtab_##sym[] \
- __attribute__((section("__ksymtab_strings" ",\"a\",@note #"), aligned(1))) \
+ __attribute__((section("__ksymtab_strings" ",\"a\",%note @"), aligned(1))) \
= VMLINUX_SYMBOL_STR(sym); \
extern const struct kernel_symbol __ksymtab_##sym; \
__visible const struct kernel_symbol __ksymtab_##sym \
__used \
- __attribute__((section("___ksymtab" sec "+" #sym ",\"a\",@note #"), used)) \
+ __attribute__((section("___ksymtab" sec "+" #sym ",\"a\",%note @"), used)) \
= { (unsigned long)&sym, __kstrtab_##sym }
#if defined(__KSYM_DEPS__)
diff --git a/include/linux/init.h b/include/linux/init.h
index 30cd246ab2ad..b4f1bb5403b4 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -163,7 +163,7 @@ extern bool initcall_debug;
/* extern const unsigned long __kentry_##sym; */ \
static /* __visible */ const unsigned long __kentry_##sym \
__used \
- __attribute__((section("___kentry" "+" #sym ",\"a\",@note #"), used)) \
+ __attribute__((section("___kentry" "+" #sym ",\"a\",%note @"), used)) \
= (unsigned long)&sym;
#else
#define LTO_REFERENCE_INITCALL(x)
[toc] | [prev] | [next] | [standalone]
| From | Nicholas Piggin <npiggin@gmail.com> |
|---|---|
| Date | 2016-08-05 14:30 +0200 |
| Message-ID | <s2Mqd-7rU-11@gated-at.bofh.it> |
| In reply to | #1457002 |
On Fri, 05 Aug 2016 12:17:27 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday, August 5, 2016 6:41:08 PM CEST Nicholas Piggin wrote:
> > On Thu, 4 Aug 2016 12:06:41 -0500
> > Segher Boessenkool <segher@kernel.crashing.org> wrote:
> >
> > > On Thu, Aug 04, 2016 at 06:10:57PM +0200, Arnd Bergmann wrote:
> > > > On Thursday, August 4, 2016 9:47:13 PM CEST Nicholas Piggin wrote:
> > > >
> > > > > + __used \
> > > > > + __attribute__((section("___kentry" "+" #sym ",\"a\",@note #"), used)) \
> > > >
> > > >
> > > > I've just started testing this, but the first problem I ran into
> > > > is that @ and # are special characters that have an architecture
> > > > specific meaning to the assembler. On ARM, you need "%note @" instead
> > > > of "@note #".
> > >
> > > That comment trick (I still feel guilty about it) causes more problems
> > > than it solves. Please don't try to use it :-)
> >
> > Yeah that's a funny hack. I don't think it's required though, but I'm just
> > running through some more tests.
> >
> > I think I found an improvement with the thin archives as well -- we were
> > still building symbol table after removing the s option (that only avoids
> > index). "S" is required to not build symbol table.
> >
> > I'll send out an RFC on a slightly more polished patch series shortly.
>
>
> I could not find Nico's patches, but based on the information in his
> presentation at
>
> https://www.linuxplumbersconf.org/2015/ocw//system/presentations/3369/original/slides.html#(1)
>
> I created a patch for ARM that mirrors what you have for powerpc, see
> below.
Great, thanks for jumping in. I posted another set which is a lot improved
you should pick up.
> I have successfully built normal-sized kernels with this (not tried
> running them). Unfortunately, the build time for "allyesconfig"
> kernel explodes, the final link time is now in the hours instead of
> minutes (no exact numbers unfortunately, it takes too long to
> reproduce),
That's becase we need to coalesce the new sections properly into the
output file. binutils does not cope with vast number of sections in
final linked file and spends all its time in hash lookup then explodes
usually.
> and I also get link errors for the .text.fixup section
> for any users of __put_user() in really large kernels:
> net/batman-adv/batman-adv.o:(.text.fixup+0x4): relocation truncated to fit: R_ARM_JUMP24 against `.text.batadv_log_read'
This may be fixed by fixing the linker script to bring in the new
sections properly (see new patchset).
If not, then if you can combine the sections rather than have them
consecutive in the output, e.g.,:
*(.text .text.fixup)
Rather than
*(.text)
*(.text.fixup)
Then the linker has more freedom to rearrange them. I realize it's
not that simple with ARM's .text.fixup, but maybe that helps you
get it to work.
Thanks,
Nick
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-08-05 18:10 +0200 |
| Subject | Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures |
| Message-ID | <s2PR7-1kZ-3@gated-at.bofh.it> |
| In reply to | #1457071 |
On Friday, August 5, 2016 10:26:25 PM CEST Nicholas Piggin wrote: > On Fri, 05 Aug 2016 12:17:27 +0200 > Arnd Bergmann <arnd@arndb.de> wrote: > > and I also get link errors for the .text.fixup section > > for any users of __put_user() in really large kernels: > > net/batman-adv/batman-adv.o:(.text.fixup+0x4): relocation truncated to fit: R_ARM_JUMP24 against `.text.batadv_log_read' > > This may be fixed by fixing the linker script to bring in the new > sections properly (see new patchset). > > If not, then if you can combine the sections rather than have them > consecutive in the output, e.g.,: > > *(.text .text.fixup) > > Rather than > > *(.text) > *(.text.fixup) > > Then the linker has more freedom to rearrange them. I realize it's > not that simple with ARM's .text.fixup, but maybe that helps you > get it to work. This did the trick: diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h index 0ec807d69f18..7a3ad269fa23 100644 --- a/include/asm-generic/vmlinux.lds.h +++ b/include/asm-generic/vmlinux.lds.h @@ -433,7 +433,7 @@ * during second ld run in second ld pass when generating System.map */ #define TEXT_TEXT \ ALIGN_FUNCTION(); \ - *(.text.hot .text .text.fixup .text.unlikely) \ + *(.text.hot .text .text.* .text.fixup .text.unlikely) \ *(.ref.text) \ MEM_KEEP(init.text) \ MEM_KEEP(exit.text) \ It also got much faster again, the link time for an allyesconfig kernel is now 18 minutes instead of 10 hours, but it's still much worse than the 2 minutes I had earlier or the four minutes with the previous patch. Arnd
[toc] | [prev] | [next] | [standalone]
| From | Nicholas Piggin <npiggin@gmail.com> |
|---|---|
| Date | 2016-08-05 18:20 +0200 |
| Message-ID | <s2Q0N-1oA-9@gated-at.bofh.it> |
| In reply to | #1457197 |
On Fri, 05 Aug 2016 18:01:13 +0200 Arnd Bergmann <arnd@arndb.de> wrote: > On Friday, August 5, 2016 10:26:25 PM CEST Nicholas Piggin wrote: > > On Fri, 05 Aug 2016 12:17:27 +0200 > > Arnd Bergmann <arnd@arndb.de> wrote: > > > > and I also get link errors for the .text.fixup section > > > for any users of __put_user() in really large kernels: > > > net/batman-adv/batman-adv.o:(.text.fixup+0x4): relocation truncated to fit: R_ARM_JUMP24 against `.text.batadv_log_read' > > > > This may be fixed by fixing the linker script to bring in the new > > sections properly (see new patchset). > > > > If not, then if you can combine the sections rather than have them > > consecutive in the output, e.g.,: > > > > *(.text .text.fixup) > > > > Rather than > > > > *(.text) > > *(.text.fixup) > > > > Then the linker has more freedom to rearrange them. I realize it's > > not that simple with ARM's .text.fixup, but maybe that helps you > > get it to work. > > This did the trick: > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > index 0ec807d69f18..7a3ad269fa23 100644 > --- a/include/asm-generic/vmlinux.lds.h > +++ b/include/asm-generic/vmlinux.lds.h > @@ -433,7 +433,7 @@ > * during second ld run in second ld pass when generating System.map */ > #define TEXT_TEXT \ > ALIGN_FUNCTION(); \ > - *(.text.hot .text .text.fixup .text.unlikely) \ > + *(.text.hot .text .text.* .text.fixup .text.unlikely) \ > *(.ref.text) \ > MEM_KEEP(init.text) \ > MEM_KEEP(exit.text) \ > > > It also got much faster again, the link time for an allyesconfig > kernel is now 18 minutes instead of 10 hours, but it's still > much worse than the 2 minutes I had earlier or the four minutes > with the previous patch. Are you using the patches I just sent? Either way, you also need to do the same for data and bss sections as you are using -fdata-sections too. I've found virtually no build time regression on powerpc or x86 when those are taken care of properly (x86 numbers I sent are typo, it's not 5m20, it's 5m02). Thanks, Nick
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-08-05 21:20 +0200 |
| Subject | Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures |
| Message-ID | <s2SOZ-3fo-3@gated-at.bofh.it> |
| In reply to | #1457203 |
On Saturday, August 6, 2016 2:16:42 AM CEST Nicholas Piggin wrote: > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > > index 0ec807d69f18..7a3ad269fa23 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h > > @@ -433,7 +433,7 @@ > > * during second ld run in second ld pass when generating System.map */ > > #define TEXT_TEXT \ > > ALIGN_FUNCTION(); \ > > - *(.text.hot .text .text.fixup .text.unlikely) \ > > + *(.text.hot .text .text.* .text.fixup .text.unlikely) \ > > *(.ref.text) \ > > MEM_KEEP(init.text) \ > > MEM_KEEP(exit.text) \ > > > > > > It also got much faster again, the link time for an allyesconfig > > kernel is now 18 minutes instead of 10 hours, but it's still > > much worse than the 2 minutes I had earlier or the four minutes > > with the previous patch. > > Are you using the patches I just sent? Not yet, I was still busy with the older version, and trying to figure out exactly what went wrong in ld.bfd. FWIW, I first tried to see if the hash tables were just too small, but as it turned out that was not the problem. When I tried to change the default hash table sizes, making them bigger only made things slower. I also found the --hash-size=xxx option, which has a significant impact on runtime speed. Interestingly again, using sizes less than the default made things faster in practice. If we can work out the optimum size for the kernel build, that might shave a few minutes off the total build time. > Either way, you also need > to do the same for data and bss sections as you are using > -fdata-sections too. Right. > I've found virtually no build time regression on powerpc or x86 > when those are taken care of properly (x86 numbers I sent are typo, > it's not 5m20, it's 5m02). Interesting. I wonder if it's got something to do with the generation of the branch trampolines on ARM, as we have a lot of them on an allyesconfig. Is the 5m20 the total build time for the kernel, the time for rebuilding after a trivial change, or the time to call 'ld.bfd' once? Are you using ld.bfd on x86 or ld.gold? For me ld.gold either works and is really fast, or it crashes, depending on the configuration. I also don't think it supports big-endian ARM (which is what allyesconfig ends up using). Arnd
[toc] | [prev] | [next] | [standalone]
| From | Nicholas Piggin <npiggin@gmail.com> |
|---|---|
| Date | 2016-08-06 22:50 +0200 |
| Message-ID | <s3gHE-2dj-3@gated-at.bofh.it> |
| In reply to | #1457255 |
On Fri, 05 Aug 2016 21:16:00 +0200 Arnd Bergmann <arnd@arndb.de> wrote: > On Saturday, August 6, 2016 2:16:42 AM CEST Nicholas Piggin wrote: > > > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > > > index 0ec807d69f18..7a3ad269fa23 100644 > > > --- a/include/asm-generic/vmlinux.lds.h > > > +++ b/include/asm-generic/vmlinux.lds.h > > > @@ -433,7 +433,7 @@ > > > * during second ld run in second ld pass when generating System.map */ > > > #define TEXT_TEXT \ > > > ALIGN_FUNCTION(); \ > > > - *(.text.hot .text .text.fixup .text.unlikely) \ > > > + *(.text.hot .text .text.* .text.fixup .text.unlikely) \ > > > *(.ref.text) \ > > > MEM_KEEP(init.text) \ > > > MEM_KEEP(exit.text) \ > > > > > > > > > It also got much faster again, the link time for an allyesconfig > > > kernel is now 18 minutes instead of 10 hours, but it's still > > > much worse than the 2 minutes I had earlier or the four minutes > > > with the previous patch. > > > > Are you using the patches I just sent? > > Not yet, I was still busy with the older version, and trying to > figure out exactly what went wrong in ld.bfd. FWIW, I first tried > to see if the hash tables were just too small, but as it turned > out that was not the problem. When I tried to change the default > hash table sizes, making them bigger only made things slower. > > I also found the --hash-size=xxx option, which has a significant > impact on runtime speed. Interestingly again, using sizes less > than the default made things faster in practice. If we can > work out the optimum size for the kernel build, that might > shave a few minutes off the total build time. > > > Either way, you also need > > to do the same for data and bss sections as you are using > > -fdata-sections too. > > Right. > > > I've found virtually no build time regression on powerpc or x86 > > when those are taken care of properly (x86 numbers I sent are typo, > > it's not 5m20, it's 5m02). > > Interesting. I wonder if it's got something to do with the > generation of the branch trampolines on ARM, as we have a lot > of them on an allyesconfig. Powerpc generates quite a few branch trampolines as well, so I'm not sure if that would be the issue. Can you get a profile of the link? Are you linking with archives? Do your input archives have a symbol index built? > Is the 5m20 the total build time for the kernel, the time for > rebuilding after a trivial change, or the time to call 'ld.bfd' > once? 5m02 was the total time for x86 defconfig. With the powerpc allyesconfig build, the final link: $ time ld -EL -m elf64lppc -pie --emit-relocs --build-id --gc-sections -X -o vmlinux -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive built-in.o .tmp_kallsyms2.o real 0m15.556s user 0m13.288s sys 0m2.240s $ ls -lh vmlinux -rwxrwxr-x 1 npiggin npiggin 279M Aug 6 14:02 vmlinux Without -pie --emit-relocs it's 11.8s and 150M but I'm using emit-relocs for a post-link step. > Are you using ld.bfd on x86 or ld.gold? For me ld.gold either > works and is really fast, or it crashes, depending on the > configuration. I also don't think it supports big-endian ARM > (which is what allyesconfig ends up using). ld.bfd on both. Gold crashed on powerpc and I didn't try it on x86. Thanks, Nick
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-08-06 23:20 +0200 |
| Subject | Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures |
| Message-ID | <s3haF-2Dy-11@gated-at.bofh.it> |
| In reply to | #1457343 |
On Saturday, August 6, 2016 2:17:16 PM CEST Nicholas Piggin wrote: > On Fri, 05 Aug 2016 21:16:00 +0200 > Arnd Bergmann <arnd@arndb.de> wrote: > > > On Saturday, August 6, 2016 2:16:42 AM CEST Nicholas Piggin wrote: > > > > > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > > > > index 0ec807d69f18..7a3ad269fa23 100644 > > > > --- a/include/asm-generic/vmlinux.lds.h > > > > +++ b/include/asm-generic/vmlinux.lds.h > > > > @@ -433,7 +433,7 @@ > > > > * during second ld run in second ld pass when generating System.map */ > > > > #define TEXT_TEXT \ > > > > ALIGN_FUNCTION(); \ > > > > - *(.text.hot .text .text.fixup .text.unlikely) \ > > > > + *(.text.hot .text .text.* .text.fixup .text.unlikely) \ > > > > *(.ref.text) \ > > > > MEM_KEEP(init.text) \ > > > > MEM_KEEP(exit.text) \ > > > > > > > > > > > > It also got much faster again, the link time for an allyesconfig > > > > kernel is now 18 minutes instead of 10 hours, but it's still > > > > much worse than the 2 minutes I had earlier or the four minutes > > > > with the previous patch. > > > > > > Are you using the patches I just sent? > > > > Not yet, I was still busy with the older version, and trying to > > figure out exactly what went wrong in ld.bfd. FWIW, I first tried > > to see if the hash tables were just too small, but as it turned > > out that was not the problem. When I tried to change the default > > hash table sizes, making them bigger only made things slower. > > > > I also found the --hash-size=xxx option, which has a significant > > impact on runtime speed. Interestingly again, using sizes less > > than the default made things faster in practice. If we can > > work out the optimum size for the kernel build, that might > > shave a few minutes off the total build time. > > > > > Either way, you also need > > > to do the same for data and bss sections as you are using > > > -fdata-sections too. > > > > Right. > > > > > I've found virtually no build time regression on powerpc or x86 > > > when those are taken care of properly (x86 numbers I sent are typo, > > > it's not 5m20, it's 5m02). > > > > Interesting. I wonder if it's got something to do with the > > generation of the branch trampolines on ARM, as we have a lot > > of them on an allyesconfig. > > Powerpc generates quite a few branch trampolines as well, so > I'm not sure if that would be the issue. Can you get a profile > of the link? CPU: AMD64 family15h, speed 2600 MHz (estimated) Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 100000 samples % image name symbol name 1212556 63.6990 ld-new bfd_hash_lookup 416050 21.8563 ld-new bfd_hash_hash 64861 3.4073 no-vmlinux /no-vmlinux 59038 3.1014 ld-new bfd_hash_traverse 13873 0.7288 ld-new bfd_get_next_section_by_name 9880 0.5190 ld-new strrevcmp I've manually marked bfd_hash_hash as __attribute__((noinline)) to see it separately from bfd_hash_lookup. The vast majority of these calls seem to come from _bfd_elf_strtab_add and from bfd_get_section_by_name/bfd_get_next_section_by_name. While I first thought the hash tables were too slow, investigating further showed that most of the hash tables are really small (and appropriately sized), we just do a lot of lookups on them. > Are you linking with archives? Do your input archives have a > symbol index built? yes, and don't know. I've moved on to your new patches now, will see how that goes. > > Is the 5m20 the total build time for the kernel, the time for > > rebuilding after a trivial change, or the time to call 'ld.bfd' > > once? > > 5m02 was the total time for x86 defconfig. With the powerpc > allyesconfig build, the final link: > > $ time ld -EL -m elf64lppc -pie --emit-relocs --build-id --gc-sections -X -o vmlinux -T ./arch/powerpc/kernel/vmlinux.lds --whole-archive built-in.o .tmp_kallsyms2.o > > real 0m15.556s > user 0m13.288s > sys 0m2.240s > > $ ls -lh vmlinux > -rwxrwxr-x 1 npiggin npiggin 279M Aug 6 14:02 vmlinux > > Without -pie --emit-relocs it's 11.8s and 150M but I'm using > emit-relocs for a post-link step. Interesting, that does sound more like an ARM specific bug in ld then. > > Are you using ld.bfd on x86 or ld.gold? For me ld.gold either > > works and is really fast, or it crashes, depending on the > > configuration. I also don't think it supports big-endian ARM > > (which is what allyesconfig ends up using). > > ld.bfd on both. Gold crashed on powerpc and I didn't try it on x86. Ok. Arnd
[toc] | [prev] | [next] | [standalone]
| From | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| Date | 2016-08-03 05:30 +0200 |
| Subject | Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures |
| Message-ID | <s1V2x-5eP-5@gated-at.bofh.it> |
| In reply to | #1455443 |
"Luis R. Rodriguez" <mcgrof@kernel.org> writes: > Are linux-next builds being tested for powerpc with allyesconfig and > allmodconfig ? Yes, every single version: http://kisskb.ellerman.id.au/kisskb/target/2659/ > I have some changes I'm making and while debugging my > build issues I decided to give a clean build a shot and see linux-next > next-20160729 up to next-20160729 all have build failures without my > changes. I get: > > /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld: > drivers/built-in.o: .opd is not a regular array of opd entries > MODPOST vmlinux.o > GEN .version > CHK include/generated/compile.h > UPD include/generated/compile.h > CC init/version.o > LD init/built-in.o > /opt/gcc-4.9.0-nolibc/powerpc64-linux/bin/powerpc64-linux-ld: > drivers/built-in.o: .opd is not a regular array of opd entries > drivers/built-in.o: In function `.ipw2100_up': > ipw2100.c:(.text+0x1ff9c90): relocation truncated to fit: > R_PPC64_REL24 (stub) against symbol `.round_jiffies_relative' defined > in .text section in kernel/built-in.o And yes this is a known problem, there have been attempts to fix it, but none that quite got working. In fact it's our bug #1 :) https://github.com/linuxppc/linux/issues/1 Please use allmodconfig, which should build in general. Or one of our other defconfigs, eg. ppc64/ppc64le defconfig. cheers
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web