insmod hates RELA?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Gordon McNutt
I've compiled a module natively on an Indy (linux 2.4.0-test8), but when I try to do an insmod (2.3.9) I get this error:
RELA relocations not supported on this architecture
Correct. The Indy kernel is 32 bit ELF which uses only REL relocs.
Only the newer N32 and 64 ABI flavours use RELA relocs and we don't use those file types except for Origin kernels, therefore I'm pretty surprised to see your report.
Quoted 9 lines
I don't yet understand enough about ELF layouts to know what this means and why MIPS doesn't support it. I thought I saw a message in the archives stating that 64bit MIPS supports it, but maybe 32bit doesn't. I've tried to make sure my compiler options match those being used to compile the kernel (which works), but perhaps I'm overlooking something.
If anyone can give me some hints about what's going wrong I'd greatly appreciate it. And if you can reply to me that would be best as I don't subscribe to this list.
A possible explanation would be that you use the wrong binutils, have a corrupt module file or try to load a module for another architecture or modutils being plain broken?
Ralf
Quoted 3 lines · Ralf Baechle
A possible explanation would be that you use the wrong binutils, have a corrupt module file or try to load a module for another architecture or modutils being plain broken?
The linker tends to create empty .rela sections even if there is no input
for them. This actually is a minor error and until (unless) we modify the linker just use the quick fix for modutils that is available from my FTP site (not that these modutils actually work ;-) ).
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 4 lines · Maciej W. Rozycki
The linker tends to create empty .rela sections even if there is no input for them. This actually is a minor error and until (unless) we modify the linker just use the quick fix for modutils that is available from my FTP site (not that these modutils actually work ;-) ).
Against modutils 2.3.17. Does 2.3.17+this patch work on mips?
Index: 18.2/obj/obj_load.c
obj/obj_load.c Fri, 06 Oct 2000 21:45:44 +1100 kaos (modutils-2.3/21_obj_load.c 1.7 644) renamed from obj/obj_load.c Fri, 08 Sep 2000 16:46:27 +1100 kaos (modutils-2.3/21_obj_load.c 1.7 644) +4 -2
@@ -151,11 +151,13 @@ obj_load (int fp, Elf32_Half e_type, con #if SHT_RELM == SHT_REL case SHT_RELA: - error("RELA relocations not supported on this architecture"); + if (sec->header.sh_size) + error("RELA relocations not supported on this architecture"); return NULL; #else case SHT_REL: - error("REL relocations not supported on this architecture"); + if (sec->header.sh_size) + error("REL relocations not supported on this architecture"); return NULL; #endif
Quoted 1 line · Keith Owens
Against modutils 2.3.17. Does 2.3.17+this patch work on mips?
That's exactly my patch. ;-) Yes -- it stops complaining, but it doesn't
make it load the ipv6 module (the only one I have) successfully (the kernel crashes, IIRC). I suppose it's not a modutils' fault, though -- my development environment is not as stable as I wish so this may actually be a gcc, binutils or kernel issue. Unfortunately I cannot afford tracking it down at the moment, but I'll look into it when I can. Anyone feel free to study the case independently.
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
Quoted 12 lines · Maciej W. Rozycki
Quoted 3 lines · Ralf Baechle
A possible explanation would be that you use the wrong binutils, have a corrupt module file or try to load a module for another architecture or modutils being plain broken?
The linker tends to create empty .rela sections even if there is no input
for them. This actually is a minor error and until (unless) we modify the linker just use the quick fix for modutils that is available from my FTP site (not that these modutils actually work ;-) ).--
Review
Quoted 3 lines
(quoted diff) +3
-0+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +
On the advice of a colleague I switched to an older version of gcc (2.90.29) which got rid of the RELA problem (I was using 2.96). I've now gotten further toward my goal of inserting a module.
But I'm not there yet. insmod (2.3.9) now complains about a relocation overflow on all of the kernel symbols. I'm looking at the source for insmod now. At the moment I'm trying to figure out why insmod wants to relocate kernel symbols. After patching in the values from ksym, it tries to relocate kernel symbols along with all the local symbols. Seems like a mismatch between what insmod expects the ELF to look like and what gcc wants to generate. Maybe I'm missing a gcc option or something? Here's the options I'm using to build the module:
/usr/bin/mips-linux-gcc -D__KERNEL__ -DMODULE -I../include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strength-reduce -DMODVERSIONS -G 0 -mno-abicalls -mcpu=r5000 -pipe -fno-pic -mips2
I've looked a little more since writing the above. The relocation errors are occurring in the .bss section, where it appears insmod is iterating over all references to a symbol and doing a relocation. The type of relocation done for all symbols is associated with the 'R_MIPS_26' #define (see linux/elf.h). Does anyone know much about this? Does this mean that symbols will be relocated to a 26-bit offset from some known base? If so, then how is it supposed to deal with kernel symbols? The problem appears when insmod verifies that the symbol's address is within a certain range of the section header. Not unexpectedly, the ksyms don't satisfy this check. They're way out of there.
Is this a bug in insmod?
Anyway, thanks for the help
--Gordon
Quoted 2 lines
But I'm not there yet. insmod (2.3.9) now complains about a relocation overflow on all of the kernel symbols.
modutils 2.3.9 is quite old, the released version is up to 2.3.17. ftp.<country>.kernel.org/pub/linux/kernel/utils/modutils/v2.3.
Quoted 3 lines
I'm looking at the source for insmod
now. At the moment I'm trying to figure out why insmod wants to relocate kernel symbols.
It does not relocate kernel symbols, they have fixed values. What it does is fix up references from modules to kernel symbols, the modules have relocation references to external symbols and those external symbols have to be filled in.
Quoted 5 lines
I've looked a little more since writing the above. The relocation errors are occurring in the .bss section, where it appears insmod is iterating over all references to a symbol and doing a relocation. The type of relocation done for all symbols is associated with the '
R_MIPS_26' #define (seelinux/elf.h). Is this a bug in insmod?
Don't think so, rather it is appears to be gcc assuming that some symbols can be accessed via $GP+26 bits. I don't have a MIPS ELF manual handy at the moment so I am guessing that you need -mlong-calls for modules.
Quoted 2 lines · Keith Owens
I am guessing that you need -mlong-calls
for modules.
That was it exactly. Thanks.
--Gordon
Quoted 10 lines · Keith Owens
Quoted 5 lines
I've looked a little more since writing the above. The relocation errors are occurring in the .bss section, where it appears insmod is iterating over all references to a symbol and doing a relocation. The type of relocation done for all symbols is associated with the '
R_MIPS_26' #define (seelinux/elf.h). Is this a bug in insmod?Don't think so, rather it is appears to be gcc assuming that some symbols can be accessed via $GP+26 bits. I don't have a MIPS ELF manual handy at the moment so I am guessing that you need -mlong-calls for modules.
The kernel is compiled with -fno-PIC, so it's quite likely that there areR_MIPS_26 relocations. They are used for all of the 'j* label' instructions (with the target address encoded in the 26 LSBs of the opcode). There is no $reg+26 bits addressing mode for MIPS (but there is $reg+16 and thus there is the R_MIPS_GPREL16 relocation).
Signature · 3 lines
+ Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: [email protected], PGP key available +