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