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
