Hi there,
I wonder if it is possible to start L4Linux (possibly with some modifications) whether from GRUB directly or from a different loader than l4-loader. Is there a particular reason why L4Linux is linked against libloader.s.so? If it would not work out of the box: What has to be neccessarily provided by that (new) loader in oder to achieve that goal?
Furthermore I did not manage to link L4Linux without libloader. I tried to replace libloader by those libs that were included by libloader itself, but always get undefined references:
arch/l4/kernel/built-in.o: In function `l4env_phys_to_virt': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/main.c:200: multiple definition of `l4env_infopage' ../l4/lib/x86_586/l4v2/libl4env.p.a(startup.s.o):/home/user/src/otc_snapshot/l4/pkg/l4env/lib/src/startup.c:59: first defined here lib/lib.a(string.o): In function `memcmp': /home/user/src/otc_snapshot/l4linux-2.6/lib/string.c:553: multiple definition of `memcmp' arch/l4/kernel/built-in.o:/home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/helper_dyn.c:43: first defined here ld: Warning: size of symbol `memcmp' changed from 41 in arch/l4/kernel/built-in.o to 43 in lib/lib.a(string.o) lib/lib.a(vsprintf.o): In function `vsnprintf': /home/user/src/otc_snapshot/l4linux-2.6/lib/vsprintf.c:258: multiple definition of `vsnprintf' ../l4/lib/x86_586/l4v2/liblogserver.p.a(sprintf.s.o):/home/user/src/otc_snapshot/l4/pkg/log/lib/src/sprintf.c:46: first defined here ld: Warning: size of symbol `vsnprintf' changed from 38 in ../l4/lib/x86_586/l4v2/liblogserver.p.a(sprintf.s.o) to 1337 in lib/lib.a(vsprintf.o) lib/lib.a(vsprintf.o): In function `snprintf': /home/user/src/otc_snapshot/l4linux-2.6/lib/vsprintf.c:537: multiple definition of `snprintf' ../l4/lib/x86_586/l4v2/liblogserver.p.a(sprintf.s.o):/home/user/src/otc_snapshot/l4/pkg/log/lib/src/sprintf.c:33: first defined here ld: Warning: size of symbol `snprintf' changed from 39 in ../l4/lib/x86_586/l4v2/liblogserver.p.a(sprintf.s.o) to 40 in lib/lib.a(vsprintf.o) lib/lib.a(vsprintf.o): In function `vsprintf': /home/user/src/otc_snapshot/l4linux-2.6/lib/vsprintf.c:587: multiple definition of `vsprintf' ../l4/lib/x86_586/l4v2/liblogserver.p.a(sprintf.s.o):/home/user/src/otc_snapshot/l4/pkg/log/lib/src/sprintf.c:42: first defined here ld: Warning: size of symbol `vsprintf' changed from 35 in ../l4/lib/x86_586/l4v2/liblogserver.p.a(sprintf.s.o) to 41 in lib/lib.a(vsprintf.o) lib/lib.a(vsprintf.o): In function `sprintf': /home/user/src/otc_snapshot/l4linux-2.6/lib/vsprintf.c:604: multiple definition of `sprintf' ../l4/lib/x86_586/l4v2/liblogserver.p.a(sprintf.s.o):/home/user/src/otc_snapshot/l4/pkg/log/lib/src/sprintf.c:24: first defined here ld: Warning: size of symbol `sprintf' changed from 36 in ../l4/lib/x86_586/l4v2/liblogserver.p.a(sprintf.s.o) to 41 in lib/lib.a(vsprintf.o) arch/l4/lib/arch-i386/built-in.o: In function `l4x_proc_init': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/lib/arch-i386/../proc.c:(.text+0x0): multiple definition of `strstr' arch/l4/kernel/built-in.o:/home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/helper_dyn.c:134: first defined here ld: Warning: size of symbol `strstr' changed from 112 in arch/l4/kernel/built-in.o to 48 in arch/l4/lib/arch-i386/built-in.o ../l4/lib/x86_586/l4v2/liblogserver.p.a(doprnt.s.o): In function `LOG_doprnt': /home/user/src/otc_snapshot/l4/pkg/log/lib/src/doprnt.c:732: undefined reference to `__umoddi3' /home/user/src/otc_snapshot/l4/pkg/log/lib/src/doprnt.c:733: undefined reference to `__udivdi3' arch/l4/kernel/built-in.o: In function `setup_l4env_memory': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/main.c:(.text+0x2a4): undefined reference to `l4dm_mem_allocate' arch/l4/kernel/built-in.o: In function `free': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/main.c:291: undefined reference to `l4dm_mem_release' arch/l4/kernel/built-in.o: In function `l4x_map_below_mainmem': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/main.c:386: undefined reference to `l4rm_lookup' arch/l4/kernel/built-in.o: In function `l4x_map_upage_myself': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/main.c:439: undefined reference to `l4rm_lookup' arch/l4/kernel/built-in.o: In function `l4x_map_iomemory_from_sigma0': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/main.c:1549: undefined reference to `l4sigma0_map_iomem' arch/l4/kernel/built-in.o: In function `l4env_virt_to_phys': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/main.c:165: undefined reference to `l4dm_mem_phys_addr' arch/l4/kernel/built-in.o: In function `__cxa_atexit': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/main.c:251: undefined reference to `l4rm_lookup' arch/l4/kernel/built-in.o: In function `l4x_mbm_request_ghost': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/main.c:362: undefined reference to `l4rm_area_release' arch/l4/kernel/built-in.o: In function `l4env_free_initrd_mem': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/kernel/main.c:867: undefined reference to `l4dm_ds_list_all' arch/l4/l4lxlib/l4env/lib.a(memory.o): In function `l4lx_memory_map_virtual_page': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/l4lxlib/l4env/memory.c:23: undefined reference to `l4rm_lookup' arch/l4/l4lxlib/l4env/lib.a(memory.o): In function `l4lx_memory_page_mapped': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/l4lxlib/l4env/memory.c:66: undefined reference to `l4rm_lookup' arch/l4/l4lxlib/l4env/lib.a(task.o): In function `l4lx_task_number_allocate': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/l4lxlib/l4env/task.c:65: undefined reference to `l4ts_allocate_task' arch/l4/l4lxlib/l4env/lib.a(task.o): In function `l4lx_task_number_free': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/l4lxlib/l4env/task.c:142: undefined reference to `l4ts_free_task' arch/l4/l4lxlib/l4env/lib.a(task.o): In function `l4lx_task_create_pager': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/l4lxlib/l4env/task.c:206: undefined reference to `l4ts_create_task' arch/l4/l4lxlib/l4env/lib.a(task.o): In function `l4lx_task_delete': /home/user/src/otc_snapshot/l4linux-2.6/arch/l4/l4lxlib/l4env/task.c:252: undefined reference to `l4ts_kill_task' ../l4/lib/x86_586/l4v2/libio-ll.a(req_rel.o): In function `l4io_request_mem_region': /home/user/src/otc_snapshot/l4/pkg/generic_io/lib/clientlib/req_rel.c:70: undefined reference to `l4rm_area_release' /home/user/src/otc_snapshot/l4/pkg/generic_io/lib/clientlib/req_rel.c:70: undefined reference to `l4rm_area_release' ../l4/lib/x86_586/l4v2/librtc.a(librtc.o): In function `init_done': /home/user/src/otc_snapshot/l4/pkg/rtc/lib/client/librtc.c:33: undefined reference to `l4_scaler_tsc_to_ns' /home/user/src/otc_snapshot/l4/pkg/rtc/lib/client/librtc.c:69: undefined reference to `l4_scaler_tsc_to_us' /home/user/src/otc_snapshot/l4/pkg/rtc/lib/client/librtc.c:33: undefined reference to `l4_scaler_ns_to_tsc' ../l4/lib/x86_586/l4v2/librtc.a(librtc.o): In function `l4rtc_get_seconds_since_1970': /home/user/src/otc_snapshot/build/l4/include/x86/l4/util/rdtsc.h:268: undefined reference to `l4_scaler_tsc_to_ns' /home/user/src/otc_snapshot/build/l4/include/x86/l4/util/rdtsc.h:268: undefined reference to `l4_scaler_tsc_to_ns'
Especially I wasn't able to locate "__umoddi3" and "__udivdi3" in any library except of libloader.
I modified l4linux-2.6/arch/l4/kernel/Makefile of the latest OTC snapshot as follows:
L4LIBS = -L$(L4OBJ)/lib/$(L4_MK_ARCH)_$(L4_MK_CPU)/$(L4_MK_API) \ -L$(L4OBJ)/lib/$(L4_MK_ARCH)_$(L4_MK_CPU) \ -L$(L4OBJ)/lib \ -T../../l4/lib/x86_586/main_stat.ld --start-group -lroot.p -lsemaphore.p \ -lgeneric_ts.p \ -lloaderif.p \ -ll4util_root.p \ -ll4sys.p \ -lthread.p \ -ldm_generic.p \ -ldm_mem.p \ -ll4env_err.p \ -ll4env.p \ -lnames.p \ -lgeneric_fprov.p \ -llogserver.p \ -lnames.p \ -lc_be_minimal_log_io.p \ -lc_be_simple_mem.p \ -lc_be_mmap.p \ -lc_be_mmap_util.p \ -luclibc_support.p \ -lthread.p \ -lc_be_l4env_start_stop.p \ -ll4rm.p \ -lslab.p \ -ll4util.p -lsigma0.p -llist_alloc.p --end-group \ $(GCCLIB)
Thanks in advance.
Kind regards, Daniel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Daniel,
I wonder if it is possible to start L4Linux (possibly with some modifications) whether from GRUB directly or from a different loader than l4-loader. Is there a particular reason why L4Linux is linked against libloader.s.so? If it would not work out of the box: What has to be neccessarily provided by that (new) loader in oder to achieve that goal?
Alexander Warg posted a patch for building L4Linux without a shared libloader.so to the EMSCB mailing list in May 2006. Have you already tried this out?
Bjoern
Hi,
Basically, the Loader sets up an L4Env infopage that contains some information about the application's environment. (See l4/pkg/l4env/include/env.h). I think you will be able to find the few locations where this is done in our Loader. If you have questions, feel free to ask.
are there any further steps required in order to start L4env binaries? I created a new L4env infopage and passed its address as well as mb_flag (which is set to ~L4UTIL_MB_VALID) to the task's trampoline. In this case the semaphore initialization fails and the task terminates. When using L4UTIL_MB_VALID instead, the task starts as expected but l4env_get_infopage() returns null.
*compmgrt| [D2.0] semaphore/lib/src/semaphore.c:516:l4semaphore_init(): *compmgrt| Error: L4semaphore: failed to create semaphore thread: invalid argum *compmgrt: ent (-3)! *compmgrt| Startup: semaphore lib initialization failed (-1)!
Do I have to set up the section array of the infopage as well?
Cheers, Daniel
On Wednesday 02 May 2007 14:48, Daniel Vandersee wrote:
Hi,
Basically, the Loader sets up an L4Env infopage that contains some information about the application's environment. (See l4/pkg/l4env/include/env.h). I think you will be able to find the few locations where this is done in our Loader. If you have questions, feel free to ask.
are there any further steps required in order to start L4env binaries? I created a new L4env infopage and passed its address as well as mb_flag (which is set to ~L4UTIL_MB_VALID) to the task's trampoline. In this case the semaphore initialization fails and the task terminates. When using L4UTIL_MB_VALID instead, the task starts as expected but l4env_get_infopage() returns null.
*compmgrt| [D2.0] semaphore/lib/src/semaphore.c:516:l4semaphore_init(): *compmgrt| Error: L4semaphore: failed to create semaphore thread: invalid argum *compmgrt: ent (-3)! *compmgrt| Startup: semaphore lib initialization failed (-1)!
Do I have to set up the section array of the infopage as well?
Probably yes, because the l4env library uses this information to register code and data regions at the region mapper. Just a guess: do you filled in the memory-server in your l4env infopage, because the semaphore library, which fails to initialize depends on the thread-library which itself needs a memory-server allocation purposes and potentially failed already before the semaphore library.
greetings Stefan
Cheers, Daniel
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
Hi,
L4Linux seems to work well, although I had to comment out those two function calls in the main function of (arch/l4/kernel/main.c): 1) l4env_register_pointer_section(&__init_begin, 0, "sec-w-init"); 2) l4x_map_upage_myself();
The second call seems to be uncritical, as it simply attaches the region to the address space of l4linux - which can be done by the pager as well. The removal of the first call will probably cause problems, won't it? Wherefore .init.data has to be contigous? It seems that there are other memory regions allocated and used for DMA access.
Regards, Daniel
Hi,
On Thu May 03, 2007 at 14:14:19 +0200, Daniel Vandersee wrote:
L4Linux seems to work well, although I had to comment out those two function calls in the main function of (arch/l4/kernel/main.c):
- l4env_register_pointer_section(&__init_begin, 0, "sec-w-init");
- l4x_map_upage_myself();
The second call seems to be uncritical, as it simply attaches the region to the address space of l4linux - which can be done by the pager as well.
Probably yes.
The removal of the first call will probably cause problems, won't it? Wherefore .init.data has to be contigous? It seems that there are other memory regions allocated and used for DMA access.
init-memory is usually freed and added to the generic pool of memory and may thus be also used by DMA. Currently, init-memory isn't freed but that may change again.
Adam
l4-hackers@os.inf.tu-dresden.de