Subject: Re: insmod hates RELA?

From: Ralf Baechle <[email-masked]>
Date: Fri, 6 Oct 2000 04:51:51 +0200

On Thu, Oct 05, 2000 at 01:50:56PM -0600, Gordon McNutt wrote:

> 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.

> 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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 6 Oct 2000 12:26:28 +0200 (MET DST)

> 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 ;-) ). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Keith Owens <[email-masked]>
Date: Fri, 06 Oct 2000 21:57:02 +1100

On Fri, 6 Oct 2000 12:26:28 +0200 (MET DST), 
>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
--- 18.2/obj/obj_load.c Fri, 08 Sep 2000 16:46:27 +1100 kaos (modutils-2.3/21_obj_load.c 1.7 644)
+++ 18.2(w)/obj/obj_load.c Fri, 06 Oct 2000 21:45:44 +1100 kaos (modutils-2.3/21_obj_load.c 1.7 644)
@@ -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

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 6 Oct 2000 14:05:13 +0200 (MET DST)

> 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.

---

From: Gordon McNutt <[email-masked]>
Date: Fri, 06 Oct 2000 07:22:14 -0600

> site (not that these modutils actually work ;-) ).

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

---

From: Keith Owens <[email-masked]>
Date: Sat, 07 Oct 2000 00:51:52 +1100

>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.

>I'm looking at the source for insmod
>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.

>for all symbols is associated with the 'R_MIPS_26' #define (see linux/elf.h).

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.

---

From: Gordon McNutt <[email-masked]>
Date: Fri, 06 Oct 2000 08:52:49 -0600

Keith Owens wrote:

> I am guessing that you need -mlong-calls
> for modules.

That was it exactly. Thanks.
--Gordon

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Fri, 6 Oct 2000 17:14:16 +0200 (MET DST)

> manual handy at the moment so I am guessing that you need -mlong-calls

 The kernel is compiled with -fno-PIC, so it's quite likely that there are
R_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).