Philippe De Swert wrote:
> Hello people,
> I have a custom build module with some float operations in it. I build a
> 2.4.17 kernel for a mips32 core (BCM6348 chip). It boots up fine, busybox
> works nicely, also some other apps like dropbear and thttpd do what they are
> expected to do.
> I build everything with soft-floats using a uclibc toolchain (kernel +
> filesystem). This is the configuration of my toolchain.
> ~#mips-linux-gcc -v
> Reading specs from
> Configured with:
> --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=mips-linux-uclibc
> --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit
> --enable-target-optspace --with-gnu-ld --disable-nls --enable-multilib
> --without-float --enable-sjlj-exceptions
> Thread model: posix
> gcc driver version 3.3.4 executing gcc version 3.3.3
> The module builds fine also, but when insmodding I get the following error.
> insmod: unresolved symbol __fixdfsi
> insmod: unresolved symbol __floatsidf
> insmod: unresolved symbol __muldf3
> insmod: unresolved symbol __adddf3
> As these are all float operations I am wondering about the following things:
> 1.why they are in there? I have a soft-float toolchain....
> 2.Is there float support in the kernel? While googling for it I found a few
> things talking about FP point in the kernel. Does it have something to do with
> the Algorithmics/MIPS FPU emulator. (Although it does not work emulator or
> not. Which I expected because it should only be used by apps which emit FPU
> calls, and this should not happen because I use a softfloat toolchain). So I
> expect it does not really have something to do with this.
> 3.I took care of using the same compiler options as the kernel compilation
> uses. I guess this is the correct way, and the problems are thus not related
> to this.
> Any pointers to a solution would be helpful. I am trying woth a hard-float
> toolchain now (it only takes a while to compile everything). I could also not
> dig up anything similar in the archives.
These symbols are defined in libgcc.a, however libgcc.a is normally
compiled with options that make it incompatible with kernel modules.
There is a trick I have played to work around this. If you do a normal gcc
build and then remove gcc/libgcc.a and the gcc/libgcc directory. You can
build a kernel compatible version by doing:
export LIBGCC2_DEBUG_CFLAGS='-g -G0 -mno-abicalls -fno-pic'
The resulting libgcc.a will be compatible with the kernel. Rename it to
something like libgcckernel.a.
Now you can link the kernel module adding -lgcckernel and you should be
ready to go.