Hi Alexander,
On 26.08.19 11:18, Alexander Tormasov via users wrote:
I do not find any information about other libs used by my application. It is not printed in log, only init, init->timer and init->log_terminal: virtual address layout of core: overall [0000000000002000,0000000200000000) core image [0000000002000000,000000000362a000) ipc buffer [000000000362a000,000000000362b000) boot_info [000000000362b000,000000000362d000) stack area [0000000040000000,0000000050000000) ... [init -> timer] 0x40000000 .. 0x4fffffff: stack area [init -> timer] 0x30000 .. 0x197fff: ld.lib.so [init -> log_terminal] 0x40000000 .. 0x4fffffff: stack area [init -> log_terminal] 0x30000 .. 0x197fff: ld.lib.so [init] child "timer" announces service "Timer" [init] child "log_terminal" announces service "Terminal" Warning: void Genode::Rpc_cap_factory::free(Genode::Native_capability) not implemented - resources leaked: 0x10 no RM attachment (READ pf_addr=0x0 pf_ip=0xa95b1 from pager_object: pd='init -> test-go' thread='ep') Warning: invalid signal-context capability Warning: page-fault, pager_object: pd='init -> test-go' thread='ep' ip=0xa95b1 pf-addr=0x0
This is all what I have in log (by the way, same address for stack and ld.lib.so mean that this is different process and virtual address spaces?).
core, init, timer, log_terminal, test-go, ... are different processes with their individual address spaces. So it looks like the page fault happened already before ld.lib.so could print the memory layout for '[init -> test-go]'.
And, for fault address inside debug/ld-sel4.lib.so page fault IP address 0xa95b1 Objdump show hat first address inside is from 49440 - is it real address which will be in memory? /genode/build/x86_64/debug/ld-sel4.lib.so: file format elf64-x86-64
Disassembly of section .init:
0000000000049440 <_init>: _init(): /genode/repos/base/src/lib/ldso/startup/startup.cc:36http://startup.cc:36 void _init(void) __attribute__((used,section(".init")));
void _init(void) { /* call static constructors */ for(ld_hook *func = _lctors_end; func > _lctors_start + 1; (*--func)());49440: 48 8d 05 f9 ff ff ff lea -0x7(%rip),%rax # 49440 <_init> Does it mean that it exactly correspond (page fault IP address 0xa95b1) place below, or I should subtract something from it (not clear still for me exact list of modules in memory)? ... /genode/repos/base/src/lib/base/thread.cc:51http://thread.cc:51 Ram_allocator * const ram = env_stack_area_ram_allocator; a959f: 48 b8 88 07 00 00 00 movabs $0x788,%rax a95a6: 00 00 00 a95a9: 49 8b 44 05 00 mov 0x0(%r13,%rax,1),%rax a95ae: 48 8b 30 mov (%rax),%rsi /genode/repos/base/src/lib/base/thread.cc:52http://thread.cc:52 Ram_dataspace_capability const ds_cap = ram->alloc(ds_size); a95b1: 48 8b 06 mov (%rsi),%rax a95b4: 4c 8b 40 10 mov 0x10(%rax),%r8 a95b8: 4e 3b 04 29 cmp (%rcx,%r13,1),%r8 a95bc: 0f 85 5e 02 00 00 jne a9820 <Genode::Stack::size(unsigned long)+0x330> _ZN6Genode25Constrained_ram_allocator5allocEmNS_15Cache_attributeE(): /genode/repos/base/include/base/ram_allocator.h:89 Ram_quota_guard::Reservation ram (_ram_guard, Ram_quota{page_aligned_size}); a95c2: 48 8b 5e 10 mov 0x10(%rsi),%rbx
For ld.lib.so and test-go, the address corresponds exactly. So, the page fault appears to occur at
Ram_dataspace_capability const ds_cap = ram->alloc(ds_size);
Maybe 'env_stack_area_ram_allocator' (thread.cc:51) has not been initialized?
I wonder if your test application really needs to be started with Noux though. If it doesn't need fork() or execve(), it would probably be easier not to use Noux.
I suppose that some of emulation of generic libc implemented inside noux (like used inside libgo getpid/pthread/etc) - and this is the main reason why I try to link it. May be I am wrong ?
I would try a simple "hello world" application without Noux first and hope that libgo does not need fork, execve, wait or getpid for that. pthreads should also work without Noux.
Christian