Hi,
I'm trying to convert a custom kernel 2.4 module to 2.6. The most serious problem I'm having is that there are now some unresolved symbols with 2.6:
*** Warning: "l4rm_detach" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "kmalloc" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "l4rm_do_attach" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "l4env_err_ipcstrings" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "l4lx_thread_shutdown" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "l4lx_thread_create" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "l4_sleep" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "names_waitfor_name" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined!
I see that there is no l4_ksyms.c in l4linux 2.6 like there was in 2.4.
Secondly, I get more unresolved symbols if the objects that are linked are specified at the end of the command line instead of the beginning (linking succeeds in both cases, however). The kernel build system puts the objects at the end while the DROPS build system puts them at the beginning. Does anyone have an idea why two otherwise equivalent linking commands would cause such different behaviour depending on the position of the object arguments? Here are the two command lines (the paths are slightly different because the kernel build system always outputs to the source directory:
DROPS: gcc -o test_module.o test_dev.o main.o test_dm-client.o -r -nostdlib -nostartfiles -L../../../../../lib/x86_686/l4v2 -L/home/drops/DROPS-20050908/drops/lib/x86_686/l4v2 -L../../../../../lib/x86_686 -L/home/drops/DROPS-20050908/drops/lib/x86_686 -L../../../../../lib -L/home/drops/DROPS-20050908/drops/lib -T../../../../../lib/x86_686/main_rel.ld -ltest_lxk -ldm_generic -ldm_phys -ldm_mem
kernel: gcc -r -nostdlib -nostartfiles -L/home/drops/DROPS-20050908/drops/lib/x86_686/l4v2 -L/home/drops/DROPS-20050908/drops/lib/x86_686 -L/home/drops/DROPS-20050908/drops/lib -T/home/drops/DROPS-20050908/l4/lib/x86_686/main_rel.ld -ltest_lxk -ldm_generic -ldm_phys -ldm_mem OBJ-x86_686-l4v2/mesg_dm-client.o -o test_module.o test_dev.o main.o
Thanks, Derick
On 19/09/05, Derick Swanepoel dswanepoel@gmail.com wrote:
kernel: gcc -r -nostdlib -nostartfiles -L/home/drops/DROPS-20050908/drops/lib/x86_686/l4v2 -L/home/drops/DROPS-20050908/drops/lib/x86_686 -L/home/drops/DROPS-20050908/drops/lib -T/home/drops/DROPS-20050908/l4/lib/x86_686/main_rel.ld -ltest_lxk -ldm_generic -ldm_phys -ldm_mem OBJ-x86_686-l4v2/mesg_dm-client.o -o test_module.o test_dev.o main.o
Sorry, the above command should read: gcc -r -nostdlib -nostartfiles -L/home/drops/DROPS-20050908/drops/lib/x86_686/l4v2 -L/home/drops/DROPS-20050908/drops/lib/x86_686 -L/home/drops/DROPS-20050908/drops/lib -T/home/drops/DROPS-20050908/l4/lib/x86_686/main_rel.ld -ltest_lxk -ldm_generic -ldm_phys -ldm_mem OBJ-x86_686-l4v2/test_dm-client.o -o test_module.o test_dev.o main.o
Hi,
On Mon Sep 19, 2005 at 17:47:19 +0200, Derick Swanepoel wrote:
I'm trying to convert a custom kernel 2.4 module to 2.6. The most serious problem I'm having is that there are now some unresolved symbols with 2.6:
*** Warning: "l4rm_detach" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "kmalloc" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "l4rm_do_attach" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "l4env_err_ipcstrings" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "l4lx_thread_shutdown" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "l4lx_thread_create" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "l4_sleep" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined! *** Warning: "names_waitfor_name" [/home/drops/DROPS-20050908/l4/pkg/test/examples/module.ko] undefined!
I see that there is no l4_ksyms.c in l4linux 2.6 like there was in 2.4.
In 2.6 they're writing the EXPORT_SYMBOLS directly under the functions and not in a single file anymore. I've added a few to the bottom of the main.c file but for sure not all the needed ones. We haven't been playing around with l4 related modules lately so this is why those symbols are missing. Just add the ones you need and send the list over, I'll add them.
Secondly, I get more unresolved symbols if the objects that are linked are specified at the end of the command line instead of the beginning (linking succeeds in both cases, however). The kernel build system puts the objects at the end while the DROPS build system puts them at the beginning. Does anyone have an idea why two otherwise equivalent linking commands would cause such different behaviour depending on the position of the object arguments? Here are the two command lines (the paths are slightly different because the kernel build system always outputs to the source directory:
I guess that's because of the way ld works, it only processes the list of arguments once (if not told otherwise) and depending on the order of the objects/libs given different unresolved symbols may occur.
Adam
On 20/09/05, Adam Lackorzynski adam@os.inf.tu-dresden.de wrote:
In 2.6 they're writing the EXPORT_SYMBOLS directly under the functions and not in a single file anymore. I've added a few to the bottom of the main.c file but for sure not all the needed ones. We haven't been playing around with l4 related modules lately so this is why those symbols are missing. Just add the ones you need and send the list over, I'll add them.
Thanks Adam. I added the following to arch/l4/kernel/main.c:
EXPORT_SYMBOL(kmalloc); EXPORT_SYMBOL(l4_sleep); EXPORT_SYMBOL(l4lx_thread_create); EXPORT_SYMBOL(l4lx_thread_shutdown); EXPORT_SYMBOL(l4rm_detach); EXPORT_SYMBOL(l4rm_do_attach);
#include <l4/names/libnames.h> EXPORT_SYMBOL(names_waitfor_name);
I also needed l4env_err_ipcstrings, but it isn't defined anywhere so I added it as a dummy function to my module (as in pkg/overlay_wm/examples/xf86screen/dummy.c). I hope this is correct.
Secondly, I get more unresolved symbols if the objects that are linked are specified at the end of the command line instead of the beginning (linking succeeds in both cases, however). The kernel build system puts the objects at the end while the DROPS build system puts them at the beginning. Does anyone have an idea why two otherwise equivalent linking commands would cause such different behaviour depending on the position of the object arguments? Here are the two command lines (the paths are slightly different because the kernel build system always outputs to the source directory:
I guess that's because of the way ld works, it only processes the list of arguments once (if not told otherwise) and depending on the order of the objects/libs given different unresolved symbols may occur.
I know that one can tell ld to repeatedly search archives until no new undefined symbols are created (using --start-group and --end-group), but this didn't help. Is there another way? For now I've resorted to hacking the kernel build system to place the objects at the beginning, but I know this is not the right way.
Thanks, Derick
On Wed Sep 21, 2005 at 11:55:04 +0200, Derick Swanepoel wrote:
On 20/09/05, Adam Lackorzynski adam@os.inf.tu-dresden.de wrote:
In 2.6 they're writing the EXPORT_SYMBOLS directly under the functions and not in a single file anymore. I've added a few to the bottom of the main.c file but for sure not all the needed ones. We haven't been playing around with l4 related modules lately so this is why those symbols are missing. Just add the ones you need and send the list over, I'll add them.
Thanks Adam. I added the following to arch/l4/kernel/main.c:
EXPORT_SYMBOL(kmalloc); EXPORT_SYMBOL(l4_sleep); EXPORT_SYMBOL(l4lx_thread_create); EXPORT_SYMBOL(l4lx_thread_shutdown); EXPORT_SYMBOL(l4rm_detach); EXPORT_SYMBOL(l4rm_do_attach);
#include <l4/names/libnames.h> EXPORT_SYMBOL(names_waitfor_name);
I also needed l4env_err_ipcstrings, but it isn't defined anywhere so I added it as a dummy function to my module (as in pkg/overlay_wm/examples/xf86screen/dummy.c). I hope this is correct.
I've added those except kmalloc. How does it come that there's a kmalloc symbol? kmalloc is a static inline function in slab.h so there should not be an unresolved symbol, no?
Secondly, I get more unresolved symbols if the objects that are linked are specified at the end of the command line instead of the beginning (linking succeeds in both cases, however). The kernel build system puts the objects at the end while the DROPS build system puts them at the beginning. Does anyone have an idea why two otherwise equivalent linking commands would cause such different behaviour depending on the position of the object arguments? Here are the two command lines (the paths are slightly different because the kernel build system always outputs to the source directory:
I guess that's because of the way ld works, it only processes the list of arguments once (if not told otherwise) and depending on the order of the objects/libs given different unresolved symbols may occur.
I know that one can tell ld to repeatedly search archives until no new undefined symbols are created (using --start-group and --end-group), but this didn't help. Is there another way? For now I've resorted to hacking the kernel build system to place the objects at the beginning, but I know this is not the right way.
Well but it works nevertheless? Generally I'd recommend to use the Linux build system to build modules, should be easy with the "make -C ... M=..." syntax.
Adam
l4-hackers@os.inf.tu-dresden.de