[BusyBox] Bug: BusyBox insmod segv

Nathan Field ndf at ghs.com
Mon Nov 4 18:47:03 UTC 2002


I believe that I have found a segv bug in busybox insmod versions 0.60.4
and 0.60.5 (only versions tested) when loading MIPS kernel modules
compiled with GCC 3.2. Basically when I load some (but not all) kernel
modules arch_apply_relocation case R_MIPS_32 causes a segv because loc is
0x6:

	[snip]
  case R_MIPS_32:
    fprintf(stderr, "[arch_apply_relocation] loc is: 0x%x\n", loc);
    *loc += v;
    break;
	[snip]

The output is:
[arch_apply_relocation] R_MIPS_32 case.
[arch_apply_relocation] loc is: 0x6
Hit sighandler with 11.

Note that I have installed my own sighandler to see this. The callstack is 
roughly:
	insmod_main
	obj_relocate
	arch_apply_relocation

The eventual result of this segv is that the kernel module shows up as
"(uninitialized)". The create_module is called, but init_module is not. I 
tried searching around to see if anyone else had encountered this problem, 
but all I could find was:

[BusyBox] insmod problems *sigh*
[BusyBox] insmod problems HINT
[BusyBox] insmod problems HINT -- possible patch.
	-1 passed to obj_add_symbol in symidx: Not causing my bug, it's 
fixed in my busybox code as referenced in:
http://www.busybox.net/lists/busybox/2001-June/009221.html

Now for my setup:
82) mipsel-uclibc-gcc -v
Reading specs from 
/opt/toolchains/uclibc/bin/../lib/gcc-lib/mipsel-linux/3.2/specs
Configured with: ../gcc-3.2/configure 
--prefix=/opt/toolchains/uclibc-crosstools-1.0.0 --target=mipsel-linux 
--enable-target-optspace --disable-nls --with-gnu-ld --enable-shared 
--enable-languages=c,c++ --enable-threads 
--infodir=/opt/toolchains/uclibc-crosstools-1.0.0/info 
--mandir=/opt/toolchains/uclibc-crosstools-1.0.0/man 
--includedir=/opt/toolchains/uclibc-crosstools-1.0.0/mipsel-linux/include 
--with-gxx-include-dir=/opt/toolchains/uclibc-crosstools-1.0.0/mipsel-linux/include/g++-v3 
--disable-checking --program-transform-name=s,^,mipsel-uclibc-,
Thread model: posix
gcc version 3.2

BusyBox versions 0.60.4 and 0.60.5.

Kernel 2.4.18, modified to run on a Broadcom 7320 board (MIPS 5kf based).

Unfortunatly I don't believe that I can give the kernel module out to
anyone because it actually belongs to another company. However, I think
it's probably safe to show anyone who's interested the output when running
nm and other utilities over these modules if that would help. Ask and I 
shall deliver.

Has anyone seen this problem before? If not, can anyone see what the 
problem is? I'm guessing that GCC 3.2 is doing something differently that 
insmod isn't expecting, but I haven't figured out what yet.

	nathan

-- 
Nathan Field (ndf at ghs.com)			        Where's the humor?

"If everything seems under control, you're just not going fast enough."
        -- Mario Andretti




More information about the busybox mailing list