users April 2021

users@lists.genode.org

11 participants
7 discussions

how to debug gdb?
by Alexander Tormasov 11 May '21

11 May '21

I have an application which run somehow normally. I try to run it via gdb, using the following run file attached below (which works in the past). And now I have a problem with quota (see log below), after this message it just hangs, and my attempts to update figures in run file lead to nothing, same err. I found that in general it try to upgrade session quota as a result of rpc call return, but why? what particular parameter responsible for it? How I can find the reason? e.g. print current cap used/etc? Booting from Hard Disk... Boot failed: could not read the boot disk Booting from DVD/CD... Bender: Hello World. NOVA' NOVA Microhypervisor v8-98b501b (x86_64): Apr 7 2021 23:34:52 [gcc 8.3.0] [MBI2] [ 0] TSC:2011222 kHz BUS:1007275 kHz (measured) [ 0] CORE:0:0:0 6:f:b:0 [0] Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz [ 1] CORE:1:0:0 6:f:b:0 [0] Intel(R) Core(TM)2 Duo CPU T7700 @ 2.40GHz Hypervisor NOVA (API v8) core image [0000000000100000,0000000000cef000) binaries region [000000000029d000,0000000000cef000) free for reuse detected physical memory: 0x0000000000000000 - size: 0x000000000009fc00 use physical memory: 0x0000000000000000 - size: 0x000000000009f000 detected physical memory: 0x0000000000100000 - size: 0x00000000242df000 use physical memory: 0x0000000000100000 - size: 0x00000000242df000 reserved memory: 0x237ee000 - size: 0xbf02f0 type=-2 reserved memory: 0x9fc00 - size: 0x400 type=2 reserved memory: 0xf0000 - size: 0x10000 type=2 reserved memory: 0x243df000 - size: 0x21000 type=2 reserved memory: 0xb0000000 - size: 0x10000000 type=2 reserved memory: 0xfed1c000 - size: 0x4000 type=2 reserved memory: 0xfffc0000 - size: 0x40000 type=2 reserved memory: 0xfd000000 - size: 0x300000 type=-5 reserved memory: 0x1000000 - size: 0x800000 type=-1 reserved memory: 0x1800000 - size: 0x1c00000 type=-1 reserved memory: 0x243e2152 - size: 0x0 type=-3 Hypervisor reports 2x1 CPUs Warning: CPU has no invariant TSC. mapping: affinity space -> kernel cpu id - package:core:thread remap (0x0) -> 0 - 0:0:0) boot cpu remap (1x0) -> 1 - 1:0:0) ROM modules: ROM: [000000002398c000,000000002398c5e1) config ROM: [000000000000f000,0000000000013000) core_log ROM: [00000000242f5000,00000000243b88e0) gdb_monitor ROM: [00000000243b9000,00000000243dd0c8) gdbserver_platform.lib.so ROM: [000000002398d000,00000000239ed940) init ROM: [0000000023a0d000,0000000023b0b3a8) ld.lib.so ROM: [0000000023b0c000,0000000023ce88e8) libc.lib.so ROM: [0000000023ce9000,0000000023d23d40) libm.lib.so ROM: [00000000242b4000,00000000242d4a20) pc_uart_drv ROM: [000000000000d000,000000000000e000) platform_info ROM: [0000000023d24000,0000000023d34fb0) posix.lib.so ROM: [0000000023d35000,0000000023eea148) stdcxx.lib.so ROM: [0000000023f87000,00000000242b3ac0) test-go ROM: [00000000239ee000,0000000023a0c240) timer ROM: [0000000023eeb000,0000000023f86628) vfs.lib.so ROM: [00000000242d5000,00000000242f4b18) vfs_pipe.lib.so 36M kernel memory Genode 20.11-203-g9c8a05c12 <local changes> 530 MiB RAM and 63253 caps assigned to init [init] 0x1000000 .. 0x10ffffff: linker area [init] 0x40000000 .. 0x4fffffff: stack area [init] 0x30000 .. 0x161fff: ld.lib.so [init] parent provides [init] service "ROM" [init] service "LOG" [init] service "RM" [init] service "CPU" [init] service "PD" [init] service "IRQ" [init] service "IO_MEM" [init] service "IO_PORT" [init] child "timer" [init] RAM quota: 1800K [init] cap quota: 66 [init] ELF binary: timer [init] priority: 0 [init] provides service Timer [init] child "pc_uart_drv" [init] RAM quota: 1800K [init] cap quota: 66 [init] ELF binary: pc_uart_drv [init] priority: 0 [init] provides service Uart [init] provides service Terminal [init] child "gdb_monitor" [init] RAM quota: 255752K [init] cap quota: 466 [init] ELF binary: gdb_monitor [init] priority: 0 [init] provides service test-go [init -> timer] 0x1000000 .. 0x10ffffff: linker area [init -> gdb_monitor] 0x1000000 .. 0x10ffffff: linker area [init -> pc_uart_drv] --- UART driver started --- [init -> timer] 0x40000000 .. 0x4fffffff: stack area [init -> timer] 0x30000 .. 0x161fff: ld.lib.so [init] child "pc_uart_drv" announces service "Uart" [init] child "pc_uart_drv" announces service "Terminal" [init] child "timer" announces service "Timer" [init -> gdb_monitor] 0x40000000 .. 0x4fffffff: stack area [init -> gdb_monitor] 0x30000 .. 0x161fff: ld.lib.so [init -> gdb_monitor] 0x10c7000 .. 0x10e9fff: gdbserver_platform.lib.so [init -> gdb_monitor] 0x10e0c000 .. 0x10ffffff: libc.lib.so [init -> gdb_monitor] 0x10d70000 .. 0x10e0bfff: vfs.lib.so [init -> gdb_monitor] 0x10d36000 .. 0x10d6ffff: libm.lib.so [init -> gdb_monitor] 0x10ea000 .. 0x12a1fff: stdcxx.lib.so [init -> pc_uart_drv] open IRQ 3 [init -> pc_uart_drv] [init -> pc_uart_drv] Warning: baud_rate 0 not supported, set to default [init -> pc_uart_drv] [init -> gdb_monitor] 0x10d0f000 .. 0x10d2dfff: vfs_pipe.lib.so … [init -> gdb_monitor] Warning: unsupported ioctl (request=0x40047477) [init -> gdb_monitor] Warning: unsupported ioctl (request=0x80047476) [init -> gdb_monitor] Process target created; pid = 1 [init -> gdb_monitor] Remote debugging using /dev/terminal [init -> gdb_monitor] Error: fcntl(): command 6 not supported - vfs … [init -> gdb_monitor] Warning: Pd_session::transfer_quota not implemented [init -> gdb_monitor] upgrading quota donation for PD session (0 bytes, 4 caps) [init] child "gdb_monitor" requests resources: ram_quota=0, cap_quota=4 run file: <config verbose="yes" ld_verbose="yes"> <parent-provides> <service name="ROM" /> <service name="LOG" /> <service name="RM" /> <service name="CPU" /> <service name="PD" /> <service name="IRQ" /> <service name="IO_MEM" /> <service name="IO_PORT" /> </parent-provides> <default-route> <any-service> <parent/> <any-child/> </any-service> </default-route> <default caps="250" /> <start name="timer" caps="100"> <resource name="RAM" quantum="2M"/> <provides> <service name="Timer"/> </provides> </start> <start name="pc_uart_drv" caps="100"> <resource name="RAM" quantum="2M" /> <provides> <service name="Uart"/> <service name="Terminal"/> </provides> <config> <policy label_prefix="gdb_monitor" uart="1" /> </config> </start> <start name="gdb_monitor" caps="500"> <resource name="RAM" quantum="250M" /> <provides> <service name="test-go" /> </provides> <config verbose="yes" ld_verbose="yes"> <target name="test-go" > <config verbose="yes" ld_verbose="yes"> <vfs> <dir name="dev"> <log /> </dir> <dir name="proc"> <dir name="self"> <rom name="exe" label="test-go"/> </dir> </dir> </vfs> <libc stdout="/dev/log" stderr="/dev/log" /> </config> </target> <preserve name="RAM" quantum="50M" /> <vfs> <dir name="dev"> <log/> <terminal/> </dir> <dir name="pipe"> <pipe/> </dir> </vfs> <libc stdout="/dev/log" stderr="/dev/log" pipe="/pipe"/> </config> </start> </config>

6 16

Announcement: Sculpt OS 21.03 released
by Norman Feske 03 May '21

03 May '21

Hello everyone, we just released the new version 21.03 of Sculpt OS today! You can find a fresh system image at the Sculpt download page: https://genode.org/download/sculpt Of course, the new version comes with updated documentation: https://genode.org/documentation/articles/sculpt-21-03 https://genode.org/documentation/sculpt-21-03.pdf (PDF) You can find the official news announcement at: https://genode.org/news/sculpt-os-release-21.03 To get a quick overview of the most prominent changes, please have a look at the following article: https://genodians.org/nfeske/2020-09-17-sculpt-os Have fun sculpting! Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

2 2

Restart able block devices
by Uwe 30 Apr '21

30 Apr '21

Hello all, I have seen the Video (0). At the end there is the question how to make drivers for block devices restart able. The only limiting factor for this is state, according to the video. To store state in restart able processes raft(1) was invented. Especially this implementation has enough modularity to be adaptable to store its data on raw block devices. Another key part of the solution is transactional application of log segments. For this 3 fixed root blocks are needed. Every time you need to apply some segment to a root block you overwrite first a pointer (block number) in the root block with the address of the log segment you want to apply. >From this time on after reading something from that root block and anything pointed to from it you apply that segment. Ok, you will never implement it that way. You load a raft process with the data on restart and continue to run from this loaded data as if you had written that pointer this instant. Now you prepare the next root block by doing a cow operation on the data reachable from the old root block. At last you set the version field in the new root block and set the segment pointer to an empty value. Now you need to look at the version fields of all 3 root blocks on storage. There are 6 permutations of them but only one of them will fulfill the equation H(a,b)=c. (with H as a cryptographic hash) This permutation assigns to every one of the root blocks a letter. The letter a is for overwrite, the letter b is for backup and the letter c is for the current root block. The new version field is calculated H(b,c) and the new root is written to a. I think that allows fully transactional restart able block devices. The storage of the root blocks can but doesn't have to be on the same device of the Filesystem the root blocks are managing. (1)https://github.com/canonical/raft (0)https://video.fosdem.org/2021/D.microkernel/microkernel_pluggable_device_…

2 2

how to open elf file image from inside genode? libbacktrace question
by Alexander Tormasov 12 Apr '21

12 Apr '21

During port of libbacktrace code from gcc compiler I found that I need to be able to read a.out or similar file in runtime. This library try to read original executable file and parse it for functions addresses/etc, as a part of garbage collection for golang (it parse call stack in some specific way using gcc-specific calls). I have to port to genode the following code from src/lib/gcc/libbacktrace/fileline.c: for (pass = 0; pass < 5; ++pass) { int does_not_exist; switch (pass) { case 0: filename = state->filename; break; case 1: filename = getexecname (); break; case 2: filename = "/proc/self/exe"; break; case 3: filename = "/proc/curproc/file"; break; case 4: snprintf (buf, sizeof (buf), "/proc/%ld/object/a.out", (long) getpid ()); filename = buf; break; default: abort (); } best idea is to implement library call getexecname(), e.g. as a part of libc. Anyway, this is complex question, because we need to be able to open it and read a content later. How to configure this in run file? PS for better understanding why I need this - call stack where it is called, from gdb: #0 fileline_initialize (state=0x29000, error_callback=0x1198543 <error_callback>, data=0x405fe770) at /var/services/homes/admin/gen/21.02/contrib/libbacktrace-cabcd83bc903137f607eda3a65eb09feaa5f507e/src/lib/gcc/libbacktrace/fileline.c:102 #1 0x000000000119a9a5 in backtrace_pcinfo (state=0x29000, pc=0x1198610, callback=0x119808e <callback>, error_callback=0x1198543 <error_callback>, data=0x405fe770) at /var/services/homes/admin/gen/21.02/contrib/libbacktrace-cabcd83bc903137f607eda3a65eb09feaa5f507e/src/lib/gcc/libbacktrace/fileline.c:177 #2 0x000000000119accc in unwind (context=0x405fe420, vdata=0x405fe700) at /var/services/homes/admin/gen/21.02/contrib/libbacktrace-cabcd83bc903137f607eda3a65eb09feaa5f507e/src/lib/gcc/libbacktrace/backtrace.c:91 #3 0x00000000011a87e9 in _Unwind_Backtrace (trace=0x119abfc <unwind>, trace_argument=0x405fe700) at /genodelabs-genode-2491eee/contrib/gcc-3cade18cf9defeefa714aa91de3b157fbad4aa18/src/noux-pkg/gcc/libgcc/unwind.inc:307 #4 0x000000000119ada2 in backtrace_full (state=0x29000, skip=0x0, callback=0x119808e <callback>, error_callback=0x1198543 <error_callback>, data=0x405fe770) at /var/services/homes/admin/gen/21.02/contrib/libbacktrace-cabcd83bc903137f607eda3a65eb09feaa5f507e/src/lib/gcc/libbacktrace/backtrace.c:127 #5 0x0000000001198611 in runtime_callers (skip=0x2, locbuf=0xc42000e8d8, m=0x20, keep_thunks=0x0) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/runtime/go-callers.c:207 #6 0x00000000010fdf28 in runtime.callers (skip=0x1, locbuf=...) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/traceback_gccgo.go:56 #7 0x00000000010d8f7d in runtime.mcommoninit (mp=0xc42000e800) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:546 #8 0x00000000010db6c5 in runtime.allocm (_p_=0xc420008000, fn=0x121e298 <runtime.mspinning..f>, allocatestack=0x0) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:1466 #9 0x00000000010dbdb2 in runtime.newm (fn=0x121e298 <runtime.mspinning..f>, _p_=0xc420008000) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:1769 #10 0x00000000010dc360 in runtime.startm (_p_=0xc420008000, spinning=0x1) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:1925 #11 0x00000000010dc702 in runtime.wakep () at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:2006 #12 0x00000000010dfabf in __go_go (fn=0x10d72f2, arg=0x0) at /var/services/homes/admin/gen/21.02/contrib/libgo-281260d9bdc27fefb62c00310025c54e1e629a2e/src/lib/gcc/libgo/go/runtime/proc.go:3144

5 17

Main menu of Sculpt/Genode too long to fit on screen
by reza.fathzadeh＠yahoo.com 09 Apr '21

09 Apr '21

Hello Genode developers, First of all, I have to say, Sculpt OS (and Genode framework in general) are one of the most interesting projects that I am extremely excited for their future. I ran into this issue, when you add a sufficient number of modules to a running sculpt instance, the main menu stretches outside the screen and without a way to scroll down, the only way to get them back is to remove some components. I was wondering if you are thinking of a better UI? Also, as 'depot' are frequently accessed and needed in a daily OS, would you think it'd be a good idea to bring organize 'depot' in a more accessible spot? Right now, you have to click many times. Thanks, Reza

3 2

Linux Driver Porting Advice
by John J. Karcher 08 Apr '21

08 Apr '21

Hello Everyone, I have been (very slowly) trying my hand at adding the missing Wacom touchscreen functionality to the "usb_hid" driver, and I am encountering some of the friction Stefan describes in his recent Genodians article on porting Linux drivers. (I have the additional handicap of not knowing what I'm doing, but that just makes it a learning experience. ;^) ) In that context, I'd like to ask for a little advice. Since the "usb_hid" driver is generally working, the main problem is implementing missing functions. After some fumbling, I have settled on commenting out sections of "dummies.c" and pulling more files in from the Linux source (rather than copying massive chunks into local files). To do this, I am adding files to "usb_hid.list", then doing "prepare_port dde_linux" and "make drivers/usb_hid". First question: Is this the right basic idea? Using this approach, I have been able to reduce the number of build errors. It looks like there are only a few left (although this could easily be a mirage). But I'm stumbling on conflicting headers, which has led me to an interesting discovery - the "build/x86_64/var/libcache/usb_hid_include/include/include/include/linux/" directory, which is filled with symlinks to "repos/dde_linux/src/drivers/usb_hid/lx_emul.h". Second question: Where is this controlled? I assume that if I pull in the real "device.h", for example, I should be able to remove "device.h" from a list somewhere that generates these symlinks. Is that correct? Finally, if anyone has any general advice, I'm all ears! Thanks! -- John J. Karcher devuser(a)alternateapproach.com

2 2

[set,get,make,swap]context from glibc for amd64 implementation and question for Norman
by Alexander Tormasov 08 Apr '21

08 Apr '21

as a part of efforts related to golang port I make separate patch for 21.02 genode related to implementation of setcontext/getcontext/makecontext/swapcontext family in libc as a base I borrow some code from glibc, and remove related files (mostly _ucontext.h/ucontext.h) from genode related 2 patches are in https://github.com/tor-m6/genode.git in 21.02 repo main one contains implementation to be applied to libc port aux patch contains only simple test for these functions, you can run it as I need also to add C support for alloc_secondary_stack/free_secondary_stack in dummies.cc to be able to use them during allocation of stack for makecontext/etc (it should work even in C files - current code do requires C++, I even can’t test patch without them). May be this is wrong place for the wrappers… current problems with the patch: is support only x86_64 (while can be easily extended to arm64) on nova (while should work on other OSes), and it do not support signals save/restore (while seems that not many of them supported by genode currently). Also some removal of code from libc is not that clear and correct (implement it in patch). Question for Norman (and may be other maintainers): is it suitable for main genode code, or I should keep patch only in my fork? Is it worth to make a pull request? Sincerely, Alexander

3 19

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users April 2021