I write some sample application to run inside Genode over seL4 inside VM with 4Gb. and, I see a problem with LD, saying something with memory (in the end of log): [init -> test-go] Error: LD: exception during program load: 'Genode::Region_map::Region_conflict' any ideas what cause and how to get mode info? I suspect again incorrect config in runscript, while similar test-cache app runs ok
thanks!
<config> <parent-provides> <service name="LOG"/> <service name="CPU"/> <service name="PD"/> <service name="ROM"/> <service name="IO_MEM"/> </parent-provides> <default-route> <any-service> <parent/> </any-service> </default-route> <default caps="1000"/> <start name="test-go"> <resource name="RAM" quantum="128M"/> </start> </config>
Bender: Hello World.
Boot config: parsing cmdline 'sel4 disable_iommu' Boot config: console_port = 0x3f8 Boot config: debug_port = 0x3f8 Boot config: disable_iommu = true module #0: start=0xfd29000 end=0xffff330 size=0x2d6330 name='image.elf' Physical Memory Region from 0 size 9fc00 type 1 Physical Memory Region from 9fc00 size 400 type 2 Physical Memory Region from dc000 size 24000 type 2 Physical Memory Region from 100000 size afeec000 type 1 Adding physical memory region 0x100000-0xaffec000 Physical Memory Region from affec000 size 2000 type 2 Physical Memory Region from affee000 size d000 type 3 Physical Memory Region from afffb000 size 5000 type 4 Physical Memory Region from fec00000 size 1000 type 2 Physical Memory Region from fed00000 size 1000 type 2 Physical Memory Region from fed04000 size 1000 type 2 Physical Memory Region from fee00000 size 1000 type 2 Physical Memory Region from ffc00000 size 400000 type 2 Physical Memory Region from 1000000000 size 50000000 type 1 Adding physical memory region 0x100000000-0x150000000 Got framebuffer info in multiboot2. Current video mode is at physical address=b0000000 pitch=10240 resolution=2560x1600@32 type=1 Detected 1 boot module(s): ***WARNING*** SKIM window not enabled, this machine is probably vulernable to Meltdown (https://www.meltdownattack.com), consider enabling Kernel loaded to: start=0x200000 end=0xaa5000 size=0x8a5000 entry=0x201209 ACPI: RSDT paddr=0xaffee000 ACPI: RSDT vaddr=0xaffee000 ACPI: FADT paddr=0xaffee040 ACPI: FADT vaddr=0xaffee040 ACPI: FADT flags=0xd ACPI: MADT paddr=0xaffee200 ACPI: MADT vaddr=0xaffee200 ACPI: MADT apic_addr=0xfee00000 ACPI: MADT flags=0x1 ACPI: MADT_APIC apic_id=0x0 ACPI: MADT_IOAPIC ioapic_id=0 ioapic_addr=0xfec00000 gsib=0 ACPI: MADT_ISO bus=0 source=0 gsi=2 flags=0x0 ACPI: MADT_ISO bus=0 source=14 gsi=14 flags=0x4 ACPI: MADT_ISO bus=0 source=15 gsi=15 flags=0x4 ACPI: 1 CPU(s) detected ELF-loading userland images from boot modules: size=0x1140000 v_entry=0x2000018 v_start=0x2000000 v_end=0x3140000 p_start=0x10000000 p_end=0x11140000 Moving loaded userland images to final location: from=0x10000000 to=0xaa5000 size=0x1140000 Starting node #0 with APIC ID 0 Mapping kernel window is done vt-x: not supported Booting all finished, dropped to user space :phys_mem_16k: Allocator 0x2fe7730 dump: Block: [0000000000200000,0000000000240000) size=256K avail=256K max_avail=256K => mem_size=262144 (0 MB) / mem_avail=262144 (0 MB)
Warning: memory in range [0000000100000000,0000000140000000) is unavailable (due to limited untyped cnode range) Warning: memory in range [0000000140000000,0000000148000000) is unavailable (due to limited untyped cnode range) Warning: memory in range [0000000148000000,000000014c000000) is unavailable (due to limited untyped cnode range) Warning: memory in range [000000014e000000,000000014f000000) is unavailable (due to limited untyped cnode range) Warning: memory in range [000000014f000000,000000014f400000) is unavailable (due to limited untyped cnode range) Warning: memory in range [000000014f400000,000000014f600000) is unavailable (due to limited untyped cnode range) Warning: memory in range [000000014f600000,000000014f700000) is unavailable (due to limited untyped cnode range) Warning: memory in range [000000014f700000,000000014f780000) is unavailable (due to limited untyped cnode range) Warning: memory in range [000000014f780000,000000014f7c0000) is unavailable (due to limited untyped cnode range) Warning: memory in range [000000014f7e0000,000000014f7e4000) is unavailable (due to limited untyped cnode range) Warning: memory in range [000000014f7e4000,000000014f7e5000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000000150000000,0000000160000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000000160000000,0000000180000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000000180000000,0000000200000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000000200000000,0000000400000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000000400000000,0000000800000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000000800000000,0000001000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000001000000000,0000002000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000002000000000,0000004000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000004000000000,0000008000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000008000000000,0000408000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000408000000000,0000608000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000608000000000,0000708000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000708000000000,0000788000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [0000788000000000,00007c8000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [00007c8000000000,00007e8000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [00007e8000000000,00007f8000000000) is unavailable (due to limited untyped cnode range) Warning: device memory in range [00007f8000000000,0000800000000000) is unavailable (due to limited untyped cnode range) virtual address layout of core: overall [0000000000002000,0000000200000000) core image [0000000002000000,0000000003140000) ipc buffer [0000000003140000,0000000003141000) boot_info [0000000003141000,0000000003143000) stack area [0000000040000000,0000000050000000) Warning: need physical memory, but Platform object not constructed yet Warning: need physical memory, but Platform object not constructed yet Warning: need physical memory, but Platform object not constructed yet boot module 'config' (372 bytes) boot module 'test-go' (10088 bytes) boot module 'ld.lib.so' (1002416 bytes) boot module 'init' (345536 bytes) Warning: need physical memory, but Platform object not constructed yet Genode sculpt-19.07 <local changes> 2721 MiB RAM and 261141 caps assigned to init Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x1 Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x2 Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x4 Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x8 [init -> test-go] Error: LD: exception during program load: 'Genode::Region_map::Region_conflict' Kernel: Thread 'ep' died because of an uncaught exception [init -> test-go] Error: Uncaught exception of type 'Genode::Region_map::Region_conflict' [init -> test-go] Warning: abort called - thread: ep Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x10 Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x20 [init] child "test-go" exited with exit value 1
Sincerely, Alexander
Hello Alexander,
On Mon, Aug 05, 2019 at 01:10:57 CEST, Alexander Tormasov via users wrote:
I write some sample application to run inside Genode over seL4 inside VM with 4Gb. and, I see a problem with LD, saying something with memory (in the end of log): [init -> test-go] Error: LD: exception during program load: 'Genode::Region_map::Region_conflict'
The loader is not able to load the binary because it cannot fulfill the memory-region requirements of the application.
any ideas what cause and how to get mode info? I suspect again incorrect config in runscript, while similar test-cache app runs ok
First we need to know how your sample application looks like. Please investigate the binary with the following command.
genode-x86-objdump -p <binary>
For example the output with the log test looks like follows.
genode-x86-objdump -p bin/test-log
bin/test-log: file format elf64-x86-64
Program Header: PHDR off 0x0000000000000040 vaddr 0x0000000000200040 paddr 0x0000000000000000 align 2**3 filesz 0x0000000000000150 memsz 0x0000000000000150 flags r-- INTERP off 0x000000000000430b vaddr 0x000000000100330b paddr 0x000000000100330b align 2**0 filesz 0x000000000000000a memsz 0x000000000000000a flags r-- LOAD off 0x0000000000001000 vaddr 0x0000000001000000 paddr 0x0000000001000000 align 2**12 filesz 0x0000000000004a44 memsz 0x0000000000004a44 flags r-x LOAD off 0x0000000000006000 vaddr 0x0000000001005000 paddr 0x0000000001005000 align 2**12 filesz 0x0000000000000de4 memsz 0x0000000000000fd0 flags rw- DYNAMIC off 0x0000000000006b38 vaddr 0x0000000001005b38 paddr 0x0000000001005b38 align 2**5 filesz 0x00000000000002ac memsz 0x00000000000002ac flags rw- EH_FRAME off 0x0000000000005920 vaddr 0x0000000001004920 paddr 0x0000000001004920 align 2**2 filesz 0x0000000000000124 memsz 0x0000000000000124 flags r--
Dynamic Section: NEEDED ld.lib.so HASH 0x0000000001003318 STRTAB 0x0000000001003930 SYMTAB 0x0000000001003480 STRSZ 0x0000000000000516 SYMENT 0x0000000000000018 DEBUG 0x0000000000000000 PLTGOT 0x0000000001005c78 PLTRELSZ 0x00000000000002a0 PLTREL 0x0000000000000007 JMPREL 0x0000000001004070 RELA 0x0000000001003e48 RELASZ 0x0000000000000228 RELAENT 0x0000000000000018
This tells us which RAM regions are used
LOAD off 0x0000000000001000 vaddr 0x0000000001000000 paddr 0x0000000001000000 align 2**12 filesz 0x0000000000004a44 memsz 0x0000000000004a44 flags r-x LOAD off 0x0000000000006000 vaddr 0x0000000001005000 paddr 0x0000000001005000 align 2**12 filesz 0x0000000000000de4 memsz 0x0000000000000fd0 flags rw-
and that the binary is indeed dynamically linked.
NEEDED ld.lib.so
Also may I ask if test-go is a custom application (and if it uses Go as the binary name hints)?
Greets
the output of utility:
test-go: file format elf64-x86-64
Program Header: PHDR off 0x0000000000000040 vaddr 0x0000000000001040 paddr 0x0000000000000000 align 2**3 filesz 0x0000000000000150 memsz 0x0000000000000150 flags r-- INTERP off 0x0000000000001000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**0 filesz 0x000000000000000a memsz 0x000000000000000a flags r-- LOAD off 0x0000000000001000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12 filesz 0x000000000000023c memsz 0x000000000000023c flags r-- LOAD off 0x0000000000002000 vaddr 0x0000000000001000 paddr 0x0000000000001000 align 2**12 filesz 0x0000000000000100 memsz 0x0000000000000100 flags rw- DYNAMIC off 0x0000000000002028 vaddr 0x0000000000001028 paddr 0x0000000000001028 align 2**3 filesz 0x00000000000000d8 memsz 0x00000000000000d8 flags rw- EH_FRAME off 0x0000000000001230 vaddr 0x0000000000000230 paddr 0x0000000000000230 align 2**2 filesz 0x000000000000000c memsz 0x000000000000000c flags r--
Dynamic Section: NEEDED ld.lib.so HASH 0x0000000000000010 STRTAB 0x0000000000000190 SYMTAB 0x0000000000000058 STRSZ 0x000000000000009f SYMENT 0x0000000000000018 DEBUG 0x0000000000000000
5 авг. 2019 г., в 12:59, Christian Helmuth <christian.helmuth@genode-labs.commailto:christian.helmuth@genode-labs.com> написал(а):
Hello Alexander,
genode-x86-objdump -p bin/test-log
Also may I ask if test-go is a custom application (and if it uses Go as the binary name hints)?
yes, this is custom application which compiled separately and linked by gccgo instead of g++ from the same bootstrap genode gcc compiler suit
this is link command line (while some addresses are cut - everything except libgcc.a taken from the locally compiled bootstrap infrastructure (taken from make -C build/x86_64/ KERNEL=sel4 test/app result)
genode/tool/19.05/bin/genode-x86-gccgo -static -Wl,-melf_x86_64 -Wl,-gc-sections -Wl,-z -Wl,max-page-size=0x1000 -Wl,--dynamic-list=genode/repos/base/src/ld/genode_dyn.dl -nostdlib -Wl,-nostdlib -Wl,-Ttext=0x01000000 -m64 -mcmodel=large -Wl,--dynamic-linker=ld.lib.so -Wl,--eh-frame-hdr -Wl,-rpath-link=. -Wl,-T -Wl,genode/repos/base/src/ld/genode_dyn.ld -Wl,--whole-archive -Wl,--start-group main.o $libs/base/base.lib.a ld.lib.so -Wl,--no-whole-archive -Wl,--end-group /usr/local/genode/tool/19.05/bin/../lib/gcc/x86_64-pc-elf/8.3.0/64/libgcc.a -o test-go
anything wrong here?
Hi Alexander,
I see two issues from the info you provided (see below).
On Mon, Aug 05, 2019 at 15:39:57 CEST, Alexander Tormasov via users wrote:
LOAD off 0x0000000000001000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12 filesz 0x000000000000023c memsz 0x000000000000023c flags r-- LOAD off 0x0000000000002000 vaddr 0x0000000000001000 paddr 0x0000000000001000 align 2**12 filesz 0x0000000000000100 memsz 0x0000000000000100 flags rw-
The load addresses (vaddr) of your program segments are unrealistically low at 0x0 and 0x1000. At least the first segment is not loadable because Genode region maps (aka virtual memory) starts at 0x1000 to detect nullptr dereferences.
genode/tool/19.05/bin/genode-x86-gccgo -static -Wl,-melf_x86_64 -Wl,-gc-sections -Wl,-z -Wl,max-page-size=0x1000 -Wl,--dynamic-list=genode/repos/base/src/ld/genode_dyn.dl -nostdlib -Wl,-nostdlib -Wl,-Ttext=0x01000000 -m64 -mcmodel=large -Wl,--dynamic-linker=ld.lib.so -Wl,--eh-frame-hdr -Wl,-rpath-link=. -Wl,-T -Wl,genode/repos/base/src/ld/genode_dyn.ld -Wl,--whole-archive -Wl,--start-group main.o $libs/base/base.lib.a ld.lib.so -Wl,--no-whole-archive -Wl,--end-group /usr/local/genode/tool/19.05/bin/../lib/gcc/x86_64-pc-elf/8.3.0/64/libgcc.a -o test-go
The command-line arguments for gccgo contradict as they demand a statically linked binary by "-static" but also use the linker script for dynamically-linked components "-Wl,-T -Wl,genode/repos/base/src/ld/genode_dyn.ld" and "--dynamic-linker=ld.lib.so".
You have two options: remove "-static" or use the correct command-line arguments for statically linked components. You may deduce the correct arguments by changing the LIBS variable in your target.mk to
LIBS = base-sel4
and runnning
make -C build/x86_64/ KERNEL=sel4 test/app VERBOSE=
Don't forget to change your init configuration for the statically-linked component like follows to prevent the use of the dynamic linker ld.lib.so.
<start name="test-go" ld="no"> <resource name="RAM" quantum="128M"/> </start>
Regards
I'd highly recommend trying a different kernel if possible. NOVA and hw are the most reliable in my experience, followed by Linux and FOC. For x86_64, at least, seL4 support seems to come in last for me. Plenty of run scripts work on NOVA and hw but not on seL4, so I'd suggest you debug your component on those first, then switch to seL4.
On Mon, Aug 5, 2019, 8:28 AM Christian Helmuth < christian.helmuth@genode-labs.com> wrote:
Hi Alexander,
I see two issues from the info you provided (see below).
On Mon, Aug 05, 2019 at 15:39:57 CEST, Alexander Tormasov via users wrote:
LOAD off 0x0000000000001000 vaddr 0x0000000000000000 paddr0x0000000000000000 align 2**12
filesz 0x000000000000023c memsz 0x000000000000023c flags r-- LOAD off 0x0000000000002000 vaddr 0x0000000000001000 paddr0x0000000000001000 align 2**12
filesz 0x0000000000000100 memsz 0x0000000000000100 flags rw-The load addresses (vaddr) of your program segments are unrealistically low at 0x0 and 0x1000. At least the first segment is not loadable because Genode region maps (aka virtual memory) starts at 0x1000 to detect nullptr dereferences.
genode/tool/19.05/bin/genode-x86-gccgo -static -Wl,-melf_x86_64 -Wl,-gc-sections -Wl,-z -Wl,max-page-size=0x1000 -Wl,--dynamic-list=genode/repos/base/src/ld/genode_dyn.dl -nostdlib -Wl,-nostdlib -Wl,-Ttext=0x01000000 -m64 -mcmodel=large -Wl,--dynamic-linker=ld.lib.so -Wl,--eh-frame-hdr -Wl,-rpath-link=. -Wl,-T -Wl,genode/repos/base/src/ld/genode_dyn.ld -Wl,--whole-archive -Wl,--start-group main.o $libs/base/base.lib.a ld.lib.so -Wl,--no-whole-archive -Wl,--end-group
/usr/local/genode/tool/19.05/bin/../lib/gcc/x86_64-pc-elf/8.3.0/64/libgcc.a
-o test-go
The command-line arguments for gccgo contradict as they demand a statically linked binary by "-static" but also use the linker script for dynamically-linked components "-Wl,-T -Wl,genode/repos/base/src/ld/genode_dyn.ld" and "--dynamic-linker=ld.lib.so".
You have two options: remove "-static" or use the correct command-line arguments for statically linked components. You may deduce the correct arguments by changing the LIBS variable in your target.mk to
LIBS = base-sel4
and runnning
make -C build/x86_64/ KERNEL=sel4 test/app VERBOSE=
Don't forget to change your init configuration for the statically-linked component like follows to prevent the use of the dynamic linker ld.lib.so.
<start name="test-go" ld="no"> <resource name="RAM" quantum="128M"/> </start>Regards
Christian Helmuth Genode Labs
https://www.genode-labs.com/ · https://genode.org/ https://twitter.com/GenodeLabs · /ˈdʒiː.nəʊd/
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
-
Alexander Tormasov -
Christian Helmuth -
Nobody III