SHN_MIPS_SCOMMON

SHN_MIPS_SCOMMON

[Greg Satz]

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

SHN_MIPS_SCOMMON

[Greg Satz]

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

Re: SHN_MIPS_SCOMMON

[Ralf Baechle]

On Fri, Jul 20, 2001 at 04:15:28PM -0600, Greg Satz wrote:

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

Rotten kernel error.  Upgrade to >= 2.4.5.

  Ralf

Re: SHN_MIPS_SCOMMON

[Greg Satz]

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

on 7/20/01 7:30 PM, Ralf Baechle at ralf@oss.sgi.com wrote:

> On Fri, Jul 20, 2001 at 04:15:28PM -0600, Greg Satz wrote:
> 
>> When making modules for the 2.4.2 kernel, gcc and friends will generate
> 
> Rotten kernel error.  Upgrade to >= 2.4.5.
> 
> Ralf
> 

Re: SHN_MIPS_SCOMMON

[Greg Satz]

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

on 7/20/01 7:30 PM, Ralf Baechle at ralf@oss.sgi.com wrote:

> On Fri, Jul 20, 2001 at 04:15:28PM -0600, Greg Satz wrote:
> 
>> When making modules for the 2.4.2 kernel, gcc and friends will generate
> 
> Rotten kernel error.  Upgrade to >= 2.4.5.
> 
> Ralf
> 

Re: SHN_MIPS_SCOMMON

[Ralf Baechle]

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

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

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

Re: SHN_MIPS_SCOMMON

[H . J . Lu]

On Sat, Jul 21, 2001 at 02:11:20PM +0200, Ralf Baechle wrote:
> 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

Send me a testcase. I will fix the linker.


H.J.

Re: SHN_MIPS_SCOMMON

[Greg Satz]

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

on 7/21/01 11:41 AM, H . J . Lu at hjl@lucon.org wrote:

> On Sat, Jul 21, 2001 at 02:11:20PM +0200, Ralf Baechle wrote:
>> 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
> 
> Send me a testcase. I will fix the linker.
> 
> 
> H.J.
> 

Re: SHN_MIPS_SCOMMON

[Greg Satz]

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

on 7/21/01 11:41 AM, H . J . Lu at hjl@lucon.org wrote:

> On Sat, Jul 21, 2001 at 02:11:20PM +0200, Ralf Baechle wrote:
>> 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
> 
> Send me a testcase. I will fix the linker.
> 
> 
> H.J.
> 

Re: SHN_MIPS_SCOMMON

[H . J . Lu]

On Sat, Jul 21, 2001 at 12:12:29PM -0600, Greg Satz wrote:
> 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.

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


H.J.

Re: SHN_MIPS_SCOMMON

[Ralf Baechle]

On Sat, Jul 21, 2001 at 10:41:44AM -0700, H . J . Lu wrote:

> > .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
> 
> Send me a testcase. I will fix the linker.

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

  Ralf

Re: SHN_MIPS_SCOMMON

[Ralf Baechle]

On Sat, Jul 21, 2001 at 11:13:16AM -0700, H . J . Lu wrote:

> On Sat, Jul 21, 2001 at 12:12:29PM -0600, Greg Satz wrote:
> > 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.
> 
> In that case, it is no linker bug. I believe -G 0 is required for
> mips kernel modules.

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

  Ralf

Re: SHN_MIPS_SCOMMON

[H . J . Lu]

On Sat, Jul 21, 2001 at 08:56:59PM +0200, Ralf Baechle wrote:
> On Sat, Jul 21, 2001 at 11:13:16AM -0700, H . J . Lu wrote:
> 
> > On Sat, Jul 21, 2001 at 12:12:29PM -0600, Greg Satz wrote:
> > > 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.
> > 
> > In that case, it is no linker bug. I believe -G 0 is required for
> > mips kernel modules.
> 
> Actually for all code; we don't support GP optimization in any of our code
> models.

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.

Re: SHN_MIPS_SCOMMON

[Ralf Baechle]

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

> > Actually for all code; we don't support GP optimization in any of our code
> > models.
> 
> 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
> 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.

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