Re: SHN_MIPS_SCOMMON

[Ralf Baechle <ralf@oss.sgi.com>]

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