Re: Kernel module complying and unresolved symbol(s)

[Hans-Peter Nilsson <hp@xxxxxxxx>]

> From: Simon Posnjak <simon.posnjak@xxxxxxx.net>
> Date: Tue, 21 Sep 2004 00:48:48 +0200

> insmod: unresolved symbol __fixunsdfsi
> insmod: unresolved symbol __Mul
> insmod: unresolved symbol __muldi3
> 
> This particular module was build as show in buildlog-1.txt
> 
> I found that all three symbols are part of libgcc.a and that module was
> complied with cris-axis-elf-gcc.

The libgcc.a you need to resolve those symbols, would have been
compiled by cris-axis-linux-gnu-gcc.  Alternatively, use the
option "-mlinux" with gcc-cris, but better to call the right
compiler directly by its canonical name than through the wrapper
script.

> Next I changed the compiler from cris-gcc to cris-axis-linux-gnu-gcc.

Good.  (For the record and the audience, you need
/usr/local/cris/bin in your $PATH; maybe you only have
/usr/local/cris if this fails.)

> The result was that I got:
>  
> cris-ld: liblatency_rt.a(liblatency_rt_a-latency-module.o): uses non-prefixed symbols, but writing file with _-prefixed symbols
> Bad value: failed to merge target specific data of file liblatency_rt.a(liblatency_rt_a-latency-module.o)
> 
> at link time. So I added -Wa,--underscore to the flags and the module 
> built. (see buildlog-2.txt)

Wrong way around.  Use cris-axis-linux-gnu-gcc to link instead.
Or use the right linker options, but again it's always better to
call the linker through the compiler.  Less (target-specific)
options to remember...

> But when I tried to insmod the module it reported:
> 
> /var/ttt/modules # insmod latency_rt.o
> Using latency_rt.o
> insmod: unresolved symbol __fixunsdfsi
> 
> I found with google that this function converts double to unsigned int.

Because the kernel doesn't use floating-point, it doesn't have
and doesn't export that symbol.

Does RTAI really use need to use floating-point arithmetic, or
is there a bug in the module you compile?  A missing cast
somewhere or something not constant?

> -Am I complying the kernel module with wrong switches or the switches are OK, but
> I need to add (rip from libgcc) __fixunsdfsi function to the lib section of arch/cris?

You must compile with cris-axis-linux-gnu-gcc, or with the
"-mlinux" option.

> (And when I am at it, I can all so add __Mul and __muldi3[all most all other arch have 
> this one]) (As I understand this problem I need to add the missing FP instructions/functions)

I can't parse that as a question.

> -Do I understand correctly that the difference between non-prefixed and prefixed symbols
> is that non-prefixed symbols are static and prefixed are dynamic - they are going to be
> assigned at load time? 

Wrong.  The "_-prefixed..." message is a clear indication that
you used the wrong compiler option to compile or link.  Just use
cris-axis-linux-gnu-gcc and never worry about target-specific
compiler options again.  Again, you never need to call the
linker directly.

> -If so then the kernel module should be compiled with prefixed symbols, right?

The "if so" yields "if false", so it'd be illogical to answer
that.

> -Also when complying kernel module I should never use -mlinux, correct?

Wrong.  Either use that option or compile with
cris-axis-linux-gnu-gcc.

Since the build system Axis provides does the right thing, I
don't understand why you have this problem.

> -When I do file <kernel-module.o> i get:
> rtai_hal.o: ELF 32-bit LSB relocatable, version 1 (SYSV), not stripped
> but when I do the same on user-module.o i get:
> latency_rt.o: ELF 32-bit LSB relocatable, version 1 MathCoPro/FPU/MAU Required (SYSV), not stripped
> Can someone explain this please?

A bug in the "file" utility.  Report to the maintainer of the
"file" utility.  I suggest you use the "readelf" utility
instead.

> Content-Disposition: attachment; filename=buildlog-2.txt

> tuff1/delo/playground/RealTime/rtai-test5/rtai-testsuite/kern/latency'
> if cris-axis-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/stuff1/delo/playground/RealTime/rtai-3.1-test5/rtai-testsuite/kern/latency -I../../..  -D__KERNEL__ -I/stuff1/delo/playground/RealTime/linux-2.4.26/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -Wa,--underscore -DMODULE -DEXPORT_SYMTAB -D__IN_RTAI__ -D__linux__ -I/stuff1/delo/playground/RealTime/rtai-3.1-test5/rtai-core/include -I../../../rtai-core/include    -MT liblatency_rt_a-latency-module.o -MD -MP -MF ".deps/liblatency_rt_a-latency-module.Tpo" \
>   -c -o liblatency_rt_a-latency-module.o `test -f 'latency-module.c' || echo '/stuff1/delo/playground/RealTime/rtai-3.1-test5/rtai-testsuite/kern/latency/'`latency-module.c; \

Remove the "-Wa,--underscore" option.

> cris-ar cru liblatency_rt.a liblatency_rt_a-latency-module.o
> cris-ranlib liblatency_rt.a
> cris-ld --whole-archive liblatency_rt.a -r -o latency_rt.o

 That last line should have been something like (untested):
cris-axis-linux-gnu-gcc --nostdlib -static -Wl,--whole-archive liblatency_rt.a -Wl,--no-whole-archive -lgcc -r -o latency_rt.o

 For education only, that should be roughly equivalent to (also untested):
cris-ld -mcrislinux --whole-archive liblatency_rt.a --no-whole-archive `cris-axis-linux-gnu-gcc --print-libgcc-file-name` -r -o latency_rt.o

If you ever need to call the linker directly, rethink.  You can
always call the linker from the compiler.  There's an option
"-v" to the compiler that shows you how it calls the linker
which I think would have helped here.  I recommend to use it
*only* to get a better picture if something goes wrong with the
compiler options.

brgds, H-P