Subject: SHN_MIPS_SCOMMON

From: Greg Satz <[email-masked]>
Date: Fri, 20 Jul 2001 16:15:28 -0600

When making modules for the 2.4.2 kernel, gcc and friends will generate
SHN_MIPS_SCOMMON ELF segments (0xff03). Unfortunately insmod (obj_reloc.c)
doesn't know how to relocate these symbols and the module page faults at
location 4 upon initialization.

Is this a bug in obj_reloc.c not handling SHN_MIPS_SCOMMON like SHN_COMMON
or should everyone who makes mips kernel modules be using the -fno-common
gcc flag?

Thanks,
Greg

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 21 Jul 2001 03:30:20 +0200

> When making modules for the 2.4.2 kernel, gcc and friends will generate

Rotten kernel error.  Upgrade to >= 2.4.5.

  Ralf

---

From: Greg Satz <[email-masked]>
Date: Sat, 21 Jul 2001 03:22:17 -0600

Hi Ralf, maybe I am missing something but after downloading and some perusal
I don't see where the newer (2.4.5) kernel addresses this problem. At the
risk of being redundant, the issue, as I see it, is the use of SCOMMON
symbols in ELF section SHN_MIPS_SCOMMON (0xff03). These symbols are
overlooked when insmod relocates symbols in the SHN_COMMON ELF section. They
end up in the kernel with a value of 4. Upon being referenced, the module
gets a page fault opps.

The file obj/obj_reloc.c in the modutils package is where the SHN_COMMON
symbol relocation work is performed. Using the gcc flag -fno-common forces
all commons info bss thus preventing the problem. We do this as a
work-around now.

The question is whether the gcc -fno-common flag is the real fix or is
obj/obj_reloc.c deficient. I have a patch that appears to work for
obj/obj_reloc.c

We create the problem situation by declaring variables in one file as extern
and defining them in another. The compiler puts these variables in the
SCOMMON segment instead of the COMMON segment.

Thanks,
Greg

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 21 Jul 2001 14:11:20 +0200

On Sat, Jul 21, 2001 at 03:22:17AM -0600, Greg Satz wrote:

> and defining them in another.

You have common declarations that's declarations without static or extern
keywords and initalization.  Perfectly legal.

> The compiler puts these variables in the SCOMMON segment instead of the
> COMMON segment.

Only if you don't compile / assemble / link with -G 0.

.scommon shouldn't ever be in a kernel object.  It seems that ld started
to move .common objects to .scommon from a certain version on, so 2.4.5
now passes the right options.  .scommon is used in global pointer
optimizations which doesn't work under Linux anyway as we use $gp ($28)
for a different purpose.  So modutils should reject such a module right
away.

  Ralf

---

From: "H . J . Lu" <[email-masked]>
Date: Sat, 21 Jul 2001 10:41:44 -0700

> to move .common objects to .scommon from a certain version on, so 2.4.5

Send me a testcase. I will fix the linker.

H.J.

---

From: Greg Satz <[email-masked]>
Date: Sat, 21 Jul 2001 12:12:29 -0600

The problem I ran into was making NFS as a kernel module. The resulting
sunrpc.o module crashed when insmod was run over it. Ralf's fix that all
compiles and links use -G 0 worked for me.

Thanks,
Greg

---

From: "H . J . Lu" <[email-masked]>
Date: Sat, 21 Jul 2001 11:13:16 -0700

> compiles and links use -G 0 worked for me.

In that case, it is no linker bug. I believe -G 0 is required for
mips kernel modules.

H.J.

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 21 Jul 2001 20:55:02 +0200

> Send me a testcase. I will fix the linker.

There is no linker bug, this is just the GP optimization in action.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 21 Jul 2001 20:56:59 +0200

> In that case, it is no linker bug. I believe -G 0 is required for

Actually for all code; we don't support GP optimization in any of our code
models.

  Ralf

---

From: "H . J . Lu" <[email-masked]>
Date: Sat, 21 Jul 2001 12:03:02 -0700

> Actually for all code; we don't support GP optimization in any of our code

Even for the user space code? Do you have a testcase to show what
should be the desired behavior? As I understand, the SHN_MIPS_SCOMMON
section only appears in the relocatable files. You won't see it in
executables nor DSOs. Are there any problems with SHN_MIPS_SCOMMON
in .o files? Can we always pass `-G 0' to the assemebler for Linux.

H.J.

---

From: Ralf Baechle <[email-masked]>
Date: Sun, 22 Jul 2001 01:20:16 +0200

On Sat, Jul 21, 2001 at 12:03:02PM -0700, H . J . Lu wrote:

> Even for the user space code?

Yes.  GP optimization isn't comparible with SVR4 PIC code.  I don't see a
fundamental problem to get that to work but gcc refuses the use of -G with
PIC code.

What would limit the value of the GP optimization is that for alot of code
a single 64kb GP data segment is not large enough; the IRIX compiler and
Alpha binutils afaik support a multi-gp code model already.

> Do you have a testcase to show what should be the desired behavior? As I
> understand, the SHN_MIPS_SCOMMON section only appears in the relocatable
> files. You won't see it in

It's already guanteed that we never use GP optimization.  The particular
case which was reported by the user was caused ld directly which defaults to
-G 8.  That's not an issue for userspace.

  Ralf