- l4-hackers - example.com Site

ptrace
by Ryan Brown 14 Apr '13

14 Apr '13

Are there issues using ptrace under l4linux? I'm trying to debug a process using gdbserver, but when I use stepi (PTRACE_SINGLESTEP) it seems to run until the next system call. Has anyone else seen this? Is there some way to use the fiasco debugger to debug an l4linux process?

2 1

RCU performance
by Christian Prochaska 11 Apr '13

11 Apr '13

Hello, when building Fiasco.OC with multiprocessor support enabled, the unmapping of an IPC gate via 'l4_task_unmap()' appears to require at least 3 timer interrupts to occur until completion, which can make a noticable difference in overall execution time compared to the uniprocessor configuration (extreme example: https://github.com/genodelabs/genode/issues/712, in a more realistic scenario (compiling an application) the difference was still like ~2 minutes execution time with the uniprocessor configuration vs. ~6 minutes with the multiprocessor configuration). I've attached the debug output I got while trying to understand what's going on and which shows some of the RCU-related activities after each of the 3 timer interrupts (patch used for the debug messages: https://github.com/cproc/foc/commit/fa7b6f823cb29c0fc1db389ceb956d554d9e154…) According to these messages, the quiescent period had ended after the second timer interrupt and I wonder if it is really necessary to wait for a third timer interrupt before executing the corresponding callbacks. Would it work correctly with the attached patch, too? Christian

1 0

compile l4 source files: idl-parser-driver.hh:62:1: error
by yuqing wang 09 Apr '13

09 Apr '13

Hi, when I compile TUDOS/lEnv tree downloaded form svn.tudo.org , many errors apear in /todu/dice/src/parser/idl: {{{ g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../src -Wall -I../../../src -g -O2 -MT idl-parser.tab.o -MD -MP -MF .deps/idl-parser.tab.Tpo -c -o idl-parser.tab.o idl-parser.tab.cc In file included from idl-parser.yy:109:0: idl-parser-driver.hh:62:1: error： ‘token_type’ in ‘class yy::idl_parser’ does not name a type idl-parser.tab.cc: in function‘virtual int yy::idl_parser::parse()’: idl-parser.tab.cc:352:42: error： ‘idllex' not declared in this scope make[7]: *** [idl-parser.tab.o] Error 1 make[7]: Leaving directory ‘/todu/dice/src/parser/idl’ make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory ‘todu/dice/src/parser’ }}} Any help is appreciated yuqing wang

2 1

L4android mlock on vectors page causes unresolvable page fault
by Matthias Petschick 08 Apr '13

08 Apr '13

Hello, while experimenting with lvm, I noticed that mlocking the vectors page at 0xbffff000 from user space causes an unresolvable page fault (see full trace below). In particular, the lvcreate process attempts to lock its mapped memory regions when activating a volume, which includes the vectors page. While debugging this, I further noticed that L4android maps the vectors page to 0xbffff000 by default instead of 0xffff0000, configurable via CONFIG_VECTORS_BASE, however references to the hard-coded address 0xffff0000 remain in some places under arch/l4, e.g. in devicemaps_init() in arch/l4/mm/arch-arm/mmu.c. Without further investigating how the vectors page addressing is treated in L4android, I cannot say whether this is related or not. The pc in the backtrace is in special_mapping_fault, apparently because the vma for the vectors page was installed with a NULL pointer for its pages array, hence vm_private_data is also NULL when dereferenced by special_mapping_fault in if (*pages). The oops itself seems to be triggered because pfa is 0x1 and l4x_handle_pagefault refuses to resolve pagefaults for addresses < L4_PAGESIZE. Here's the associated trace: Page fault (non-resolved): pfa=1 pc=108df14 Internal error: Boom!: 410007 [#5] SMP Modules linked in: CPU: 0 Tainted: G D W (3.1.10-l4-dirty #8) PC is at special_mapping_fault+0x80/0xe0 LR is at __do_fault+0x68/0x464 pc : [<0108df14>] lr : [<01088b50>] psr: 6000001f sp : 132dbda8 ip : 00000000 fp : 0bd4eff8 r10: 00000000 r9 : 0137a1ac r8 : 00000008 r7 : 00000000 r6 : bffff000 r5 : 0605ae20 r4 : 01d38288 r3 : 000bffff r2 : 000bffff r1 : 132dbdc8 r0 : 00000000 Flags: nZCv IRQs on FIQs on Mode SYS_32 ISA ARM Segment user Process lvcreate (pid: 395, stack limit = 0x132da2f0) Stack: (0x132dbda8 to 0x132dc000) bda0: 014e54a0 00000000 01d38288 01088b50 000284d0 01fa6cc0 bdc0: 132da000 01fa6700 00000008 000bffff bffff000 00000000 014a8e20 00000000 bde0: 01d38288 00000008 0bd4eff8 060d97fc 0605ae20 000bffff 00000000 0108bfb8 be00: 000bffff 00000008 00000000 01600000 014c60e0 bffff000 0bd4c000 0605ae20 be20: 000005ff 0bd4eff8 01d38288 00000008 00000000 0108c138 0bd4eff8 00000008 be40: 00000052 01d38288 01fa6cc0 bffff000 0605ae20 132dbedc 0605ae20 0108c34c be60: 132da000 00000000 00000001 00000010 00000000 00000000 014cf754 bffff000 be80: 00000001 01d382a0 0605ae20 132dbedc 00000001 0605ae20 0605ae58 0108cff4 bea0: 00000052 00000000 00000000 132dbedc 0605ae5c 01d38288 c0000000 c0000000 bec0: bffff000 0108d068 132dbedc 132da000 00001000 00000000 00000000 00000001 bee0: 0605ae5c 00000096 bffff000 0108d8f0 00001000 0000a790 000ed0d7 00001000 bf00: 132da000 0100f854 00001000 000ed0d7 00000000 00000000 00000000 40095068 bf20: 132da000 132dbfb0 01fa6cc0 132da000 014ec0e8 133ea36c 00000000 0bec6000 bf40: 00000000 00000000 00000000 00000000 00000000 01195d88 00000000 68732363 bf60: 00000000 00000000 00000000 00000000 01fa6cc0 01fa6cc0 b3000c00 132da000 bf80: b3000e00 ef000000 00000000 f1886fb8 ffff0200 60000010 0100d84c b3000c00 bfa0: 000ed0b3 f1886fec 000ba4c8 00079560 bffff000 00001000 0000a790 000c681c bfc0: 00001000 000ed0d7 000bc08c 00000096 00000072 000ed0b3 000ad844 000ba4c8 bfe0: 000bc0e0 bf87c608 00079560 40191234 60000010 bffff000 00000000 00000000 [<0108df14>] (special_mapping_fault+0x80/0xe0) from [<01088b50>] (__do_fault+0x68/0x464) [<01088b50>] (__do_fault+0x68/0x464) from [<0108bfb8>] (handle_pte_fault+0xb0/0x1a0) [<0108bfb8>] (handle_pte_fault+0xb0/0x1a0) from [<0108c138>] (handle_mm_fault+0x90/0xc0) [<0108c138>] (handle_mm_fault+0x90/0xc0) from [<0108c34c>] (__get_user_pages+0x12c/0x2f8) [<0108c34c>] (__get_user_pages+0x12c/0x2f8) from [<0108cff4>] (__mlock_vma_pages_range.clone.2+0x78/0x80) [<0108cff4>] (__mlock_vma_pages_range.clone.2+0x78/0x80) from [<0108d068>] (do_mlock_pages+0x6c/0x148) [<0108d068>] (do_mlock_pages+0x6c/0x148) from [<0100f854>] (l4x_vcpu_entry_c+0xc74/0x1f90) [<0100f854>] (l4x_vcpu_entry_c+0xc74/0x1f90) from [<00079560>] (0x79560) Code: e1a02003 e1a0c003 e2400001 1afffff3 (e59c4000) ---[ end trace 47d173d365d03980 ]--- Segmentation fault Maybe someone with a better understanding of how L4android treats the vectors page has an idea what's going wrong here? Cheers, Matthias

2 4

How to access SD card on ARM board
by Chao-Jui Chang 07 Apr '13

07 Apr '13

Hi hackers, I want to use SD card as root file system for L4Linux. Base on my understand, we can use IO assignment in libio and let L4Linux kernel to access the devices directly. If this is correct, then next we need to choose correct driver in L4Linux's config menu. However, some device is platform specific, for example, "SDHCI support on Samsung S3C SoC" requires PLAT_SAMSUNG. This option is not available in L4Linux config menu. I have tried to modify the dependence in kernel's Kconfig, but it results in lots of compiler error, such as missing header files. Is this the correct way to achieve my goal? Or I need to make the driver as part of l4re ? Thanks, Chao-Jui

3 2

Re: how to debug fiasco kernel
by Björn Döbel 07 Apr '13

07 Apr '13

Hi Keqin Sun, > Hi Bjoern, > This is a screenshot(Please see the attachment "debug.png") when I used gdb. > There is no room for me to resume execution using 'g' command. The prompt of > JDB appears only after I typed 'ESC' button and nothing happened when I resume > execution(Please see the attachment "debug2.png"). you set a breakpoint on the main() function, but if you did as I told you before, the enter_kdebug() you use to actually set the breakpoint is _after_ this function entry. Therefore you do not see the breakpoint being hit. If you are worried that "hello world" is not being printed as it should, I'd recommend you try to run the application without GDB and the enter_kdebug() line first. If this fails, something else is wrong in your setup. Bjoern

1 0

Re: how to debug fiasco kernel
by Martin Unzner 07 Apr '13

07 Apr '13

I use GDB stubs exclusively, in Bochs as well as in QEMU (I did not try L4/Fiasco on other virtual machines so far, and only a few times on physical hardware). There are approaches for debugging in the L4 runtime environment, such as Valgrind and probably also GDB (although I am not sure about that). They are usually quite old and not all of them still work. If you like, you can take a look at some of the work presented at http://www.inf.tu-dresden.de/index.php?node_id=1701 and http://www.inf.tu-dresden.de/index.php?node_id=1429 . Anyway, at least with simple applications, my first approach is usually a close examination of the code: go through all your setup, and if you are unsure at some point whether you did it right or not, try to type your problem into Google. If you cannot find anything, send an e-mail to the list. People here are usually very nice and patient and they will be happy to help. Regards! Martin P.S.: I answered you using the mailing list, and I would like to ask you to use the "Reply to list" or "Reply to all" button of your e-mail client, so that everyone can follow the discussion and benefit from our findings. Am 02.04.2013 04:49, schrieb Jian Liu: > > 2013/4/2 Martin Unzner <munzner(a)os.inf.tu-dresden.de > <mailto:munzner@os.inf.tu-dresden.de>> > > > you mention bochsdbg, so maybe you want to use the Bochs GDB stub? > http://bochs.sourceforge.net/doc/docbook/user/debugging-with-gdb.html > tells you how to do so. Using GDB, you can debug all kinds of > programs on source code level. > > > Hi Martin, > > I am also wonder besides bochs, if there are other ways to > debug fiasco system on source code level. What is your usual method to > do it? > > Best, > > Jian

3 8

how to debug fiasco kernel
by Keqin Sun 01 Apr '13

01 Apr '13

Hi, I have two questions about how to debug fiasco kernel. a) Are there any debugging tools? For example, I can use bochsdbg to debug linux kernel. b) It is difficult for me to debug applications or kernel using JDB because the JDB shows lots of memory address rather than source code. what shall I do if I want more source code information when I debug. Best regards, Jimmy Sun

2 1

[Fiasco.OC] Desctruction of objects created by factory
by Sergey Grekhov 27 Mar '13

27 Mar '13

Hello, L4 hackers! I have a question about Fiasco.OC. I am a bit stuck in understanding of how objects created by factory are destroyed? For example, we have a call from user space l4_factory_create_thread(). It creates object in Fiasco (file fiasco/src/kernel/factory.cpp) and map it using call map() from fiasco/src/kernel/map_util.cpp. However, the procedure of destruction of created objects (tasks, threads, gates, irqs, vms) is not clear: it seems that there is some kind of the "garbage collector", but I can not figure out some important things. Particularly: 1) where is the code which essentially destroys created objects (call destructors)? 2) what conditions make "garbage collection" to start? 3) how "garbage collection" can be forced from user-space? As a use-case, I can propose the fork-bomb test from Genode framework: it creates lots of new Genode threads (thus, it makes a lot of new thread/gate/irq objects in Fiasco.OC). Thanks in advance for your answer. -- Best regards, Sergey Grekhov

2 1

Question regarding L4_err class usage in method commit_result.
by Sergey Grekhov 22 Mar '13

22 Mar '13

Hello, L4 experts! I have a question regarding method Kobject_iface::commit_result() in the code of Fiasco.OC. One can easily find in the code something similar to following: return commit_result(-L4_err::EPerm); And this call is very confusing: it looks like returning message tag with error, but in fact the error bit (0x8000) is not set. Moreover, some values from L4_err is intersection with enumeration L4_msg_tag::Protocol because of: 1) sign '-' used when commiting result; 2) place where both values are saved - bits 31...16 of the message tag. And, finally, there are lots of returns similar to mentioned one (return commit_result(-L4_err::EPerm)) and there are no _any_ code which checks presence of these errors in the tag. I am very confused about these strange values saved in L4_msg_tag and it appears to me that in these cases should be used method Kobject_iface::commit_error(). Can someone explain the logic behind returning values defined in class L4_err? -- Best regards, Sergey Grekhov

2 3