Error "Unknown relocation: 36" on module load on Sparc
in [Kernel]
|
Prev: [PATCH] perf: avoid synthesizing mmap() for all processes in per-thread mode perf record
Next: d_ino considered harmful
From: Vladislav Bolkhovitin on 16 Jun 2010 15:10 Hello, We in SCST project have a very strange problem on Sparc. Our main module scst.ko, if built as a module out of the kernel tree, can't be loaded and "modprobe scst" returns: FATAL: Error inserting scst (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format The following message is immediately spit out by the kernel: [ 1686.676534] module scst: Unknown relocation: 36 On x86 everything works fine. If SCST built inside the kernel, on Sparc it also works fine. We completely stuck and have no idea what could be the cause. Googling also doesn't help much. Could anybody point out a direction how to find the cause of the issue? I'm attaching Makefile we are using for you reference. Thanks, Vlad
From: Kyle McMartin on 16 Jun 2010 15:30 On Wed, Jun 16, 2010 at 11:05:41PM +0400, Vladislav Bolkhovitin wrote: > FATAL: Error inserting scst > (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format > > The following message is immediately spit out by the kernel: > [ 1686.676534] module scst: Unknown relocation: 36 > The error is caused because gcc is generating a relocation type that the kernel's module loader cannot handle. This appears to be: libelf/elf.h:#define R_SPARC_LM22 36 /* Low middle 22 bits of ... */ It doesn't occur when patched into the kernel build, since the relocations are handled at link time as opposed to load time. arch/sparc/kernel/module.c needs to be patched to support the new relocation type... Based on binutils/gas/config/tc-sparc.c and gold's sparc config this looks to be the same as the hi22 reloc... Can you test the following patch? regards, Kyle --- diff --git a/arch/sparc/include/asm/elf_64.h b/arch/sparc/include/asm/elf_64.h index e678803..8bf59f1 100644 --- a/arch/sparc/include/asm/elf_64.h +++ b/arch/sparc/include/asm/elf_64.h @@ -52,6 +52,7 @@ #define R_SPARC_11 31 #define R_SPARC_64 32 #define R_SPARC_OLO10 33 +#define R_SPARC_LM22 36 #define R_SPARC_WDISP16 40 #define R_SPARC_WDISP19 41 #define R_SPARC_7 43 diff --git a/arch/sparc/kernel/module.c b/arch/sparc/kernel/module.c index f848aad..49b1b21 100644 --- a/arch/sparc/kernel/module.c +++ b/arch/sparc/kernel/module.c @@ -207,6 +207,7 @@ int apply_relocate_add(Elf_Shdr *sechdrs, *loc32 = (*loc32 & ~0x3ff) | (v & 0x3ff); break; + case R_SPARC_LM22: case R_SPARC_HI22: *loc32 = (*loc32 & ~0x3fffff) | ((v >> 10) & 0x3fffff); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Miller on 16 Jun 2010 16:40 From: Vladislav Bolkhovitin <vst(a)vlnb.net> Date: Wed, 16 Jun 2010 23:05:41 +0400 > We in SCST project have a very strange problem on Sparc. Our main > module scst.ko, if built as a module out of the kernel tree, can't be > loaded and "modprobe scst" returns: > > FATAL: Error inserting scst > (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format > > The following message is immediately spit out by the kernel: > [ 1686.676534] module scst: Unknown relocation: 36 You're building the module with incorrect compiler flags, in particular somehow the "-mcmodel=medlow" option is not getting passed into the module build and thus the wrong code model is being used to build the module. There are a host of other sparc64 specific compiler options that must be present for a correct build as well. The only way to get it done correctly is to properly inherit the option settings made by arch/sparc/Makefile and friends in the kernel tree. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Kyle McMartin on 16 Jun 2010 16:50 On Wed, Jun 16, 2010 at 01:38:54PM -0700, David Miller wrote: > This change is incorrect. > > LM22 relocations do not get emitted for the "medlow" code model, which > is what is explicitly specified on the kernel compiler command line > for sparc64 via "-mcmodel=medlow". > > Someone this person is using incorrect CFLAGS when building their > module, and that's why they have this problem, because the compiler's > default code model on sparc64 can generate those relocations. > Yeah, just saw your other mail. Thanks for the explanation! --Kyle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Vladislav Bolkhovitin on 22 Jun 2010 15:10
David Miller, on 06/17/2010 12:35 AM wrote: > From: Vladislav Bolkhovitin <vst(a)vlnb.net> > Date: Wed, 16 Jun 2010 23:05:41 +0400 > >> We in SCST project have a very strange problem on Sparc. Our main >> module scst.ko, if built as a module out of the kernel tree, can't be >> loaded and "modprobe scst" returns: >> >> FATAL: Error inserting scst >> (/lib/modules/2.6.26-2-sparc64/extra/scst.ko): Invalid module format >> >> The following message is immediately spit out by the kernel: >> [ 1686.676534] module scst: Unknown relocation: 36 > > You're building the module with incorrect compiler flags, in > particular somehow the "-mcmodel=medlow" option is not getting passed > into the module build and thus the wrong code model is being used to > build the module. > > There are a host of other sparc64 specific compiler options that must > be present for a correct build as well. The only way to get it done > correctly is to properly inherit the option settings made by > arch/sparc/Makefile and friends in the kernel tree. Thank you. This gives us the direction away from the current dead end. We will make the needed changes in our Makefiles. But we surprised that such platform specific compiler flags have to be manually maintained by out of the kernel tree modules developers. We thought kbuild environment doing it automatically. Particularly, Documentation/kbuild/modules.txt doesn't say anything about manual platform specific flags. I added kbuild developers on CC and attached again our Makefile just in case if they would like to look at it. Thanks, Vlad |