Hi Sebastian, thanks for answer
Josef, please, take a look for this patch and for anon_mmap!
Me an Josef took a look at your anon_mmap patch. First of all we used your Genode 21.02 [1] branch and Genode world master [2]. In order to compile your "go_app" run script the patches in [3] had to be applied by us.
The call to 'alloc_secondary_stack' in 'proc.c' of libgo should use the name as its first argument, the size is the second argument. See patch [4], otherwise an arbitrary stack size will be allocated (whatever is in the rsi register).
yes, I fix this in the local copy and forget to update a patch for lingo port, because it is not tracked by git… my fault, will submit later fix with it and other problems. it is still not working in my go_app in the same reason as below, I assume alloc_secondary_stack to store stack structure and requested (rounded) size safely which seems not true (may be it worth to fix in genode code in general in base/src/lib/base/thread.cc Thread::_alloc_stack(size_t stack_size, char const *name, bool main_thread) - it seems a real mistake (I ask for my stack of stack_size but return something which I can’t use from first to last byte?)
After this 'alloc_secondary_stack' caused a page fault, because 'stack->top' will give the stack beginning aligned to 16 byte + 8 byte for x86. In case the stack size is a multiple of page size, this causes a page fault in 'memset' because the page at the end of the stack is crossed. Adding 16 byte to the allocation size quick fixes the problem. In the next iteration we received a page fault at a high address in 'src/lib/gcc/libgo/runtime/proc.c:610' in 'makeGContext' caused by the value of 'uc'. We have not debugged this any further for now.
so, will debug this, may be this is because of new setcontext implementation, and then submit a patch.
Regarding some of your questions:
I would suggest that you move 'alloc_secondary_stack' and 'free_secondary_stack' into it's own library lets call it 'libgo_support' into world and link it into libgo. In the same library I would implement the mmap_anon version. For this to work you can change the name of the 'mmap' call within libgo in file [6] there is the definition of 'sysMmap'
!//extern mmap !func sysMmap(addr unsafe.Pointer, n uintptr, prot, flags, fd int32, off uintptr) unsafe.Pointer
If one changes the "extern" directive a call to a different function is generated. For example,
! //extern mmap_anon
will lead to 'mmap_anon' being called instead of 'mmap'. The 'mmap_anon' function could handle the ANON|FIXED cases and wrap the other functionality by calling libc's mmap. This way your map anon code could reside next to libc without the risk of breaking anything generic.
in general I will move both functions to the separate lib as suggested, anon_mmap.c is a bit more complicated in logics…
ok, will do.