From: Michael Ellerman <mpe@ellerman.id.au> Date: 2016-01-12 12:14:39
From: Ulrich Weigand <redacted>
If a text section starts out with a data blob before the first
function start label, disassembly parsing doing in recordmcount.pl
gets confused on powerpc, leading to creation of corrupted module
objects.
This was not a problem so far since the compiler would never create
such text sections. However, this has changed with a recent change
in GCC 6 to support distances of > 2GB between a function and its
assoicated TOC in the ELFv2 ABI, exposing this problem.
There is already code in recordmcount.pl to handle such data blobs
on the sparc64 platform. This patch uses the same method to handle
those on powerpc as well.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
scripts/recordmcount.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Steve can we get an ack for this one, to go via powerpc? cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2016-01-12 12:14:40
From: Ulrich Weigand <redacted>
GCC 6 will include changes to generated code with -mcmodel=large,
which is used to build kernel modules on powerpc64le. This was
necessary because the large model is supposed to allow arbitrary
sizes and locations of the code and data sections, but the ELFv2
global entry point prolog still made the unconditional assumption
that the TOC associated with any particular function can be found
within 2 GB of the function entry point:
func:
addis r2,r12,(.TOC.-func)@ha
addi r2,r2,(.TOC.-func)@l
.localentry func, .-func
To remove this assumption, GCC will now generate instead this global
entry point prolog sequence when using -mcmodel=large:
.quad .TOC.-func
func:
.reloc ., R_PPC64_ENTRY
ld r2, -8(r12)
add r2, r2, r12
.localentry func, .-func
The new .reloc triggers an optimization in the linker that will
replace this new prolog with the original code (see above) if the
linker determines that the distance between .TOC. and func is in
range after all.
Since this new relocation is now present in module object files,
the kernel module loader is required to handle them too. This
patch adds support for the new relocation and implements the
same optimization done by the GNU linker.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/uapi/asm/elf.h | 2 ++
arch/powerpc/kernel/module_64.c | 27 +++++++++++++++++++++++++++
2 files changed, 29 insertions(+)
From: Steven Rostedt <rostedt@goodmis.org> Date: 2016-01-12 15:42:29
On Tue, 12 Jan 2016 23:14:22 +1100
Michael Ellerman [off-list ref] wrote:
From: Ulrich Weigand <redacted>
If a text section starts out with a data blob before the first
function start label, disassembly parsing doing in recordmcount.pl
gets confused on powerpc, leading to creation of corrupted module
objects.
This was not a problem so far since the compiler would never create
such text sections. However, this has changed with a recent change
in GCC 6 to support distances of > 2GB between a function and its
assoicated TOC in the ELFv2 ABI, exposing this problem.
There is already code in recordmcount.pl to handle such data blobs
on the sparc64 platform. This patch uses the same method to handle
those on powerpc as well.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
scripts/recordmcount.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Steve can we get an ack for this one, to go via powerpc? cheers
Acked-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2016-01-12 22:43:29
On Tue, 2016-01-12 at 10:42 -0500, Steven Rostedt wrote:
On Tue, 12 Jan 2016 23:14:22 +1100
Michael Ellerman [off-list ref] wrote:
quoted
From: Ulrich Weigand <redacted>
If a text section starts out with a data blob before the first
function start label, disassembly parsing doing in recordmcount.pl
gets confused on powerpc, leading to creation of corrupted module
objects.
This was not a problem so far since the compiler would never create
such text sections. However, this has changed with a recent change
in GCC 6 to support distances of > 2GB between a function and its
assoicated TOC in the ELFv2 ABI, exposing this problem.
There is already code in recordmcount.pl to handle such data blobs
on the sparc64 platform. This patch uses the same method to handle
those on powerpc as well.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
scripts/recordmcount.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Steve can we get an ack for this one, to go via powerpc? cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2016-01-13 13:09:25
On Tue, 2016-12-01 at 12:14:22 UTC, Michael Ellerman wrote:
From: Ulrich Weigand <redacted>
If a text section starts out with a data blob before the first
function start label, disassembly parsing doing in recordmcount.pl
gets confused on powerpc, leading to creation of corrupted module
objects.
This was not a problem so far since the compiler would never create
such text sections. However, this has changed with a recent change
in GCC 6 to support distances of > 2GB between a function and its
assoicated TOC in the ELFv2 ABI, exposing this problem.
There is already code in recordmcount.pl to handle such data blobs
on the sparc64 platform. This patch uses the same method to handle
those on powerpc as well.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2016-01-13 13:09:26
On Tue, 2016-12-01 at 12:14:23 UTC, Michael Ellerman wrote:
From: Ulrich Weigand <redacted>
GCC 6 will include changes to generated code with -mcmodel=large,
which is used to build kernel modules on powerpc64le. This was
necessary because the large model is supposed to allow arbitrary
sizes and locations of the code and data sections, but the ELFv2
global entry point prolog still made the unconditional assumption
that the TOC associated with any particular function can be found
within 2 GB of the function entry point:
func:
addis r2,r12,(.TOC.-func)@ha
addi r2,r2,(.TOC.-func)@l
.localentry func, .-func
To remove this assumption, GCC will now generate instead this global
entry point prolog sequence when using -mcmodel=large:
.quad .TOC.-func
func:
.reloc ., R_PPC64_ENTRY
ld r2, -8(r12)
add r2, r2, r12
.localentry func, .-func
The new .reloc triggers an optimization in the linker that will
replace this new prolog with the original code (see above) if the
linker determines that the distance between .TOC. and func is in
range after all.
Since this new relocation is now present in module object files,
the kernel module loader is required to handle them too. This
patch adds support for the new relocation and implements the
same optimization done by the GNU linker.
Cc: stable@vger.kernel.org
Signed-off-by: Ulrich Weigand <redacted>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>