[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2852406.SOgyPXcJfO@wuerfel>
Date: Fri, 05 Aug 2016 18:01:13 +0200
From: Arnd Bergmann <arnd@...db.de>
To: linuxppc-dev@...ts.ozlabs.org
Cc: Nicholas Piggin <npiggin@...il.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Luis R. Rodriguez" <mcgrof@...nel.org>,
linux-next@...r.kernel.org, Paul Mackerras <paulus@...ba.org>,
Fengguang Wu <fengguang.wu@...el.com>,
Guenter Roeck <linux@...ck-us.net>
Subject: Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures
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@...db.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
Powered by blists - more mailing lists