[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <f0ca0036-abe1-4252-6d30-b810dd22097d@linux.ibm.com>
Date: Thu, 6 Sep 2018 12:49:39 +0200
From: Peter Oberparleiter <oberpar@...ux.ibm.com>
To: Masami Hiramatsu <mhiramat@...nel.org>,
Stephen Rothwell <sfr@...b.auug.org.au>
Cc: "Steven Rostedt (VMware)" <rostedt@...dmis.org>,
Linux-Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
arnd@...db.de
Subject: Re: linux-next: build warnings from the build of Linus' tree
On 28.08.2018 02:43, Masami Hiramatsu wrote:
> I recently added a gcov profiling for ftrace, following Documentation/dev-tools/gcov.rst.
> 6b7dca401cb1 ("tracing: Allow gcov profiling on only ftrace subsystem")
>
> and it caused may orphan section warnings/errors on arm and powerpc64.
> We also found same error happens when CONFIG_GCOV_PROFILE_ALL=y.
> So I guess GCOV kernel subsystem broken in some environment.
I can confirm that these issues are unrelated to your commit which only
made the existing problems visible by enabling gcov-kernel profiling for
allyesconfig builds. Both problems already exist in v4.18 and likely
earlier versions.
Problem 1: link failure on arm
(https://lkml.org/lkml/2018/8/24/345)
The root cause appears to be that the arm linker script only partially
discards unneeded sections generated by the compiler when gcov-kernel
profiling is enabled.
Problem 2: linker warnings on powerpc
(https://lkml.org/lkml/2018/8/24/72)
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y adds compiler flag
-fdata-sections. This option causes GCC to create separate data sections
for data objects, including those generated by GCC internally for gcov
profiling. Since the name of these internal data objects starts with a .
(.LPBX0, .LPBX1), the resulting section name starts with "data..". As
section names starting with "data.." are used for specific purposes in
the Linux kernel, the linker script does not automatically handle them,
resulting in the "orphan section" linker warnings.
I've attached a quick fix that should address both problems. I'd
appreciate if this patch could get some testing before I post proper fix
patches.
-- >8 --
diff --git a/arch/arm/kernel/vmlinux.lds.h b/arch/arm/kernel/vmlinux.lds.h
index ae5fdff18406..2ca33277a28b 100644
--- a/arch/arm/kernel/vmlinux.lds.h
+++ b/arch/arm/kernel/vmlinux.lds.h
@@ -48,6 +48,7 @@
#define ARM_DISCARD \
*(.ARM.exidx.exit.text) \
+ *(.ARM.exidx.text.exit) \
*(.ARM.extab.exit.text) \
ARM_CPU_DISCARD(*(.ARM.exidx.cpuexit.text)) \
ARM_CPU_DISCARD(*(.ARM.extab.cpuexit.text)) \
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 7b75ff6e2fce..5cf3b90c5592 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -68,7 +68,7 @@
*/
#ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
#define TEXT_MAIN .text .text.[0-9a-zA-Z_]*
-#define DATA_MAIN .data .data.[0-9a-zA-Z_]*
+#define DATA_MAIN .data .data.[0-9a-zA-Z_]* .data..LPBX*
#define SDATA_MAIN .sdata .sdata.[0-9a-zA-Z_]*
#define RODATA_MAIN .rodata .rodata.[0-9a-zA-Z_]*
#define BSS_MAIN .bss .bss.[0-9a-zA-Z_]*
@@ -613,7 +613,7 @@
#define EXIT_DATA \
*(.exit.data .exit.data.*) \
- *(.fini_array) \
+ *(.fini_array .fini_array.*) \
*(.dtors) \
MEM_DISCARD(exit.data*) \
MEM_DISCARD(exit.rodata*)
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
Powered by blists - more mailing lists