Trying to use an AMD64 3.16 kernel built on a new Debian system fails
because
most of the kernel modules can not be loaded.
This patch handles the PLT32 relocation errors for kernels modules built
with binutils
newer then 2.31, similar to:
[ 5.742485] module: autofs4: Unknown rela relocation: 4
[ 5.742536] systemd[1]: Failed to insert module 'autofs4': Exec
format error
This patch is based on a mainline kernel patch
b21ebf2fb4cde1618915a97cc773e287ff49173e
From: "H.J. Lu" <[email protected]>
Date: Wed, 7 Feb 2018 14:20:09 -0800
Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
Signed-off-by: Woody Suwalski <[email protected]>
--- a/arch/x86/tools/relocs.c 2020-01-24 18:48:09.477919152 -0500
+++ b/arch/x86/tools/relocs.c 2020-01-24 18:48:53.645612045 -0500
@@ -763,6 +763,7 @@ static int do_reloc64(struct section *se
switch (r_type) {
case R_X86_64_NONE:
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
/*
* NONE can be ignored and PC relative relocations don't
* need to be adjusted.
--- a/arch/x86/kernel/module.c 2020-01-24 18:46:54.922670590 -0500
+++ b/arch/x86/kernel/module.c 2020-01-24 18:47:46.714112016 -0500
@@ -180,6 +180,7 @@ int apply_relocate_add(Elf64_Shdr *sechd
goto overflow;
break;
case R_X86_64_PC32:
+ case R_X86_64_PLT32:
val -= (u64)loc;
*(u32 *)loc = val;
#if 0
On Sat, 2020-01-25 at 22:16 -0500, Woody Suwalski wrote:
> Trying to use an AMD64 3.16 kernel built on a new Debian system fails
> because
> most of the kernel modules can not be loaded.
I don't recommend using the latest toolchain for 3.16 (certainly gcc 9
won't work). But I will apply this since it's such a simple fix.
Thanks for the backport.
Ben.
> This patch handles the PLT32 relocation errors for kernels modules built
> with binutils
> newer then 2.31, similar to:
> [ 5.742485] module: autofs4: Unknown rela relocation: 4
> [ 5.742536] systemd[1]: Failed to insert module 'autofs4': Exec
> format error
>
> This patch is based on a mainline kernel patch
> b21ebf2fb4cde1618915a97cc773e287ff49173e
> From: "H.J. Lu" <[email protected]>
> Date: Wed, 7 Feb 2018 14:20:09 -0800
> Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
>
> Signed-off-by: Woody Suwalski <[email protected]>
>
> --- a/arch/x86/tools/relocs.c 2020-01-24 18:48:09.477919152 -0500
> +++ b/arch/x86/tools/relocs.c 2020-01-24 18:48:53.645612045 -0500
> @@ -763,6 +763,7 @@ static int do_reloc64(struct section *se
> switch (r_type) {
> case R_X86_64_NONE:
> case R_X86_64_PC32:
> + case R_X86_64_PLT32:
> /*
> * NONE can be ignored and PC relative relocations don't
> * need to be adjusted.
> --- a/arch/x86/kernel/module.c 2020-01-24 18:46:54.922670590 -0500
> +++ b/arch/x86/kernel/module.c 2020-01-24 18:47:46.714112016 -0500
> @@ -180,6 +180,7 @@ int apply_relocate_add(Elf64_Shdr *sechd
> goto overflow;
> break;
> case R_X86_64_PC32:
> + case R_X86_64_PLT32:
> val -= (u64)loc;
> *(u32 *)loc = val;
> #if 0
>
--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.