linux-mips
[Top] [All Lists]

Re: SHN_MIPS_SCOMMON

To: Ralf Baechle <ralf@oss.sgi.com>
Subject: Re: SHN_MIPS_SCOMMON
From: Greg Satz <satz@ayrnetworks.com>
Date: Sat, 21 Jul 2001 03:22:17 -0600
Cc: <linux-mips@oss.sgi.com>
In-reply-to: <20010721033019.A22637@bacchus.dhis.org>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Microsoft-Entourage/9.0.2509
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
> 


<Prev in Thread] Current Thread [Next in Thread>