l4-hackers April 2007

l4-hackers@os.inf.tu-dresden.de

20 participants
22 discussions

L4Linux without L4Loader
by Daniel Vandersee 06 May '07

06 May '07

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

4 6

Fiasco built-in profiling
by Stefan Scheler 06 May '07

06 May '07

Hello, I'm currently trying to get fiasco's built-in profiling working. The problem is, as soon as roottask has been started, an error (mcount: tos overflow) occurs which apparently prevents profiling. Later on no gmon.out.uu is generated. Is that supposed to work? Or what am I doing wrong here? I attached a log showing the error message. From the JDB source code, it sounds like you can enable and disable kernel profiling from JDB. How can this be accomplished? Thanks for any help Stefan L4 Bootstrapper Scaning /bin/fiasco -profile -profstart -nokdb -nowait -serial -comport 1 -serial_esc Scaning /bin/sigma0 Scaning /bin/roottask Bootloader MMAP available [00000000,0009fc00) RAM (1) [0009fc00,000a0000) RAM (1) [000f0000,00100000) reserved (2) [ffb00000,00000000) reserved (2) [00100000,1fff0000) RAM (1) [1fff3000,20000000) ACPI (3) [1fff0000,1fff3000) ACPI NVS (4) Relocated mbi to [0x61000-0x611b3] Loading /bin/fiasco Loading /bin/sigma0 Loading /bin/roottask find kernel info page... found kernel info page at 0x1000 API Version: (87) experimental Sigma0 config ip:00094cd0 sp:00106100 Roottask config ip:00120000 sp:00109528 [00001000-00002000) /bin/fiasco [00002000-00052680) /bin/fiasco [00052680-0005add0) /bin/fiasco [0005b000-0005e861) /bin/fiasco [0005e880-00061000) /bin/fiasco [00090000-00099380) /bin/sigma0 [0009f000-00100000) BIOS area [00100000-00109764) bootstrap [00120000-001345d0) /bin/roottask [00135000-0013f9bb) /bin/roottask [001409c0-002be9f4) /bin/roottask [00300000-003017ec) /bin/fiasco [00302000-0038fce0) /bin/fiasco [03000000-03152c1d) Modules Memory [1fff0000-ffffffff) Deep Space Starting kernel /bin/fiasco at 003007e8 Welcome to Fiasco(ia32)! DD-L4(v2)/x86 microkernel (C) 1998-2006 TU Dresden Rev: Thu Dec 21 08:55:14 2006 compiled with gcc 4.1.1 for Pentium M Performance-critical config option(s) detected: CONFIG_SCHED_RTC is on CONFIG_ASSEMBLER_IPC_SHORTCUT is off CONFIG_PROFILE is on CONFIG_NO_FRAME_PTR is off CONFIG_JDB_ACCOUNTING is on Enabling special fully nested mode for PIC Using the RTC on IRQ 8 (1kHz) for scheduling SERIAL ESC: allocated IRQ 4 for serial uart Absolute KIP Syscalls using: Sysenter CPU: GenuineIntel (F:2:4:9) Model: Pentium 4 (Northwood/Prestonia) at 1992 MHz 64 Entry I TLB (4K or 4M pages) 64 Entry D TLB (4k or 4M pages) 12K µ-ops T Cache (8-way associative) 8 KB L1 D Cache (4-way associative, 64 bytes per line) 512 KB L2 U Cache (8-way associative, 64 bytes per line) Freeing init code/data: 24576 bytes (6 pages) Calibrating timer loop... done. SIGMA0: Hello! KIP @ 1000 Found Fiasco: KIP syscalls: yes allocated 4KB for maintenance structures Roottask. Command line found: "/bin/roottask" mcount: tos overflow 523840kB ( 511MB) total RAM (reported by bootloader) 479676kB ( 469MB) received RAM from Sigma0 1816kB ( 2MB) reserved RAM for RMGR Received I/O ports 0000-ffff Attached irqs = [ <!0> 1 <!2> 3 <!4> 5 6 7 <!8> 9 A B C D E F ] Roottask: Loading 1 module. #05: loading "/bin/hello" from [0312d000-03152c1d] to [01000000-01002eea][01003000-010055c0] entry at 0005b064 via trampoline page code symbols at [1d6fa000-1d6fb000] (4kB), lines at [1d6f7000-1d6fa000] (12kB) hello: My thread-id is 5.0 hello: My thread-id is 5.0 hello: My thread-id is 5.0

3 5

Typed Words
by Jonathan S. Shapiro 30 Apr '07

30 Apr '07

This is a very small issue. If I understand the L4 specifications correctly, typed words provided by the sender are copied to the recipient. This allows the recipient to know what was sent. An observation: The transfer of typed words exposes sender-side address values to the receiver. This is a small security violation, since there is no valid use that the receiver can make of this information. It is probably not an important issue, except that we noticed an interaction with cross-model calls. If the IPC transport replaces these addresses with zero, it becomes possible to re-encode a 64-bit typed item word into a 32-bit typed item word without losing any useful information. This appears (to us) to be useful in the implementation of IPCs that cross from (e.g.) 64-bit sender to 32-bit receiver. It does not appear to us that the receiver loses any useful information if the sender address is zeroed or truncated. Have we missed something? shap -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC

2 1

Typed items and the 'C' bit
by Jonathan S. Shapiro 30 Apr '07

30 Apr '07

The L4.x2 specification states: 1. The 'C' bits of typed items and the 't' field of IPW0 redundantly encode the number of typed items. This is intentional. 2. The sender ignores the 'C' bits, but sets them for the receiver. [This is required because the sender may set the C bits incorrectly, and the path in the kernel that interprets them must have a small, bounded number of iterations. If the kernel believes the 'C' bits of the type field, a very large number of iterations could be created and the receiver-side "frame" for words could be overwritten by the sender.] 3. The specifcation *alleges* that the C bit provides a performance advantage to the receiver in parsing the arguments. I am not convinced that [3] is true. The typed items have variable length, which means that the receiver must parse the type fields in order to iterate over them. The only complex case is string items having a non-zero 'c' (continue) bit, and the specification is explicit that for these cases the "type" field of the successor stringitem is entirely ignored. Question: does the 'C' bit provide a real advantage, or is it a historical curiosity? If there is an advantage, can somebody give an example? -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC

2 1

IPC and Multiple Execution Models
by Jonathan S. Shapiro 30 Apr '07

30 Apr '07

On amd64 (and other architectures), multiple execution models are supported by the hardware. In the case of amd64, both 64-bit and 32-bit applications can be supported simultaneously. IPC across models presents some problems. When sending from 32-bit to 64-bit, registers are widened (good), but differences in alignment rules can mean that the 64-bit receiver and the 32-bit sender do not agree about the number and lengths of indirect strings. When sending from 64-bit to 32-bit, registers are truncated, and there can be difficulties with indirect strings because of differing alignment requirements. It is definitely possible for the IDL compiler to compile for both models, and to generate cross-model calls that will avoid these problems, but I have not found any "clean" solution. On platforms that support multiple execution architectures, how do L4 systems deal with this? If this is discussed in existing documents (perhaps the IDL compiler manual?) a pointer to the document is sufficient. Thanks! -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC

3 2

getc()
by Peter Nguyen 30 Apr '07

30 Apr '07

Hi, I'm currently messing around with L4 at the moment. More specifically, i'm providing some facilities for profiling in L4 via sampling. Right now, i'm trying to implement an exception handler for the Performance Measurement Counters on the PowerPC architecture. In providing calls to these facilities via the pingpong root-task, i seem to run into problems with input. Essentially, while the root-task is waiting for user input, it seems as if the exception is not kicking in until i enter a character. The exception that should be handled is a performance monitor exception (where one of the counters overflow). Basically, the overflow takes place such that a significant amount of instructions have been executed when theoretically it should be signalled earlier. In accepting input, the root-task (which i didn't write myself) uses getc() to obtain such input. My question is basically whether getc() blocks everything and sits there until a character is received? I suspect that this is most certainly the case. If so, does anyone know whether there are other facilities available for provide an alternative means for providing input in an application. The reason why i am asking about whether getc() is a factor or not is that in providing an infinite loop, the exception/interrupt kicks in at the right time ie. when the counter overflows, the resulting counter value is slightly above the overflow value eg. the counter overflows when the contents of the register is 0x80000000. When the exception kicks in, the "final" value is 0x80000012 as opposed to a random value in the case with a root-task that requests input. Any help would be greatly appreciated. Peter N -- View this message in context: http://www.nabble.com/getc%28%29-tf3626544.html#a10126418 Sent from the L4 mailing list archive at Nabble.com.

3 6

Re: L4Linux without L4Loader
by Bjoern Doebel 26 Apr '07

26 Apr '07

Hi, > I didn't know about that patch. I just tried it and with some > modifications it builds fine. Thank you. Cool. :) > But additionally I want to load l4linux with our loader. As Christian > Helmuth stated in that thread, the loader has to emulate(?) an > L4env-environment in order to do that. What does that mean for our loader? 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. Regards, Bjoern

1 0

Debian package for Dice and DICE_INCDIR
by Neal H. Walfield 24 Apr '07

24 Apr '07

When using Adam's Debian package for dice [1], Dice's include files are installed in /usr/include. For L4 ENV to make use of them, I had to override DICE_INCDIR. This has the unfortunate effect of essentially making the system header files includable. This triggers the following error: LD_PRELOAD=/home/neal/src/tudos/build/tool/gendep/libgendep.so GENDEP_TARGET=helper_dyn.s.o GENDEP_BINARY=cc1 gcc-3.4 -c -DRAM_BASE=0x0 -DUSE_UCLIBC=y -DSYSTEM_x86_586_l4v2 -DARCH_x86 -DCPUTYPE_586 -DL4API_l4v2 -DCONFIG_L4_CALL_SYSCALLS -DCONFIG_L4_ABS_SYSCALLS -I/home/neal/src/tudos/build/pkg/loader/idl/OBJ-x86-l4v2 -I/home/neal/src/tudos/build/include/x86/l4v2 -I/home/neal/src/tudos/build/include/l4v2 -I/home/neal/src/tudos/build/include/x86 -I/home/neal/src/tudos/build/include -I/usr/include -I/home/neal/src/tudos/l4/../install/include/x86/l4v2 -I/home/neal/src/tudos/l4/../install/include/l4v2 -I/home/neal/src/tudos/l4/../install/include/x86 -I/home/neal/src/tudos/l4/../install/include -nostdinc -I/home/neal/src/tudos/build/include/x86/uclibc -I/home/neal/src/tudos/build/include/uclibc -I/home/neal/src/tudos/build/include/uclibc++ -I/home/neal/src/tudos/l4/../install/include/x86/uclibc -I/home/neal/src/tudos/l4/../install/include/uclibc -I/home/neal/src/tudos/l4/../install/include/uclibc++ -I/usr/lib/gcc/i486-linux-gnu/3.4.6/include -gstabs+ -g -O2 -fno-strict-aliasing -march=i586 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -fno-common -D__PIC__ -fPIC /home/neal/src/tudos/l4/pkg/loader/lib/runtime/helper_dyn.c -o helper_dyn.s.o /home/neal/src/tudos/l4/pkg/loader/lib/runtime/helper_dyn.c:70: error: syntax error before "__extension__" /home/neal/src/tudos/l4/pkg/loader/lib/runtime/helper_dyn.c:70: error: syntax error before '&&' token ... make[6]: *** [helper_dyn.s.o] Error 1 make[6]: Leaving directory `/home/neal/src/tudos/build/pkg/loader/lib/runtime/OBJ-x86_586-l4v2' As can be seen above -I/usr/include is present on the command line. This is due to the expansion of $(DICE_INCDIR). To work around this problem, the package could be changed to instead install the dice include files under /usr/include/dice such that setting DICE_INCDIR to /usr/include/dice would cause the dice header files to be made available for inclusion. Neal [1] http://os.inf.tu-dresden.de/~adam/dice/

2 1

Automated regression test suite for L4
by seth bollinger 18 Apr '07

18 Apr '07

Hello All, Is there an automated regression test suite for L4 that covers all (or most of) the features of the l4 kernel? Is there also an automated benchmarking suite? These would be great tools to have available for people who are porting the kernel to new platforms/dev boards, or for people who are looking to tweak/play with the kernel. Thanks, Seth

4 3

Fehler beim kompilieren...
by MHaeussi＠gmx.de 18 Apr '07

18 Apr '07

Hallo liebe Entwickler, ich habe ein Problem beim kompilieren von dem Kernel. Den Kernel will ich als Schulprojekt verwenden, dass sich mit "TPM unter Linux" beschäftigt. Grundidee ist auf dem Microkernel ein "normales" Suse Linux laufen zu lassen das fast alle TPM Funktionen unterstützt die es unter Windows gibt. Hoffentlich ist das überhaupt möglich ^^ Als er den Kompilierdurchlauf beendet habe ich 2 Fehler und es befindet sich kein Kernel im Verzeichnis. Leider kann ich mit den Fehlermeldungen nichts anfangen. Diese habe ich als Anhang beigefügt. Vorgegangen bin ich laut eurer Anleitung im Internet. lg Markus Häußler -- Markus Häußler "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

l4-hackers April 2007