Hi Alexander,
On 3/18/21 10:33 AM, Alexander Tormasov via users wrote:
One more attempt to implement [set,get,make,swap]context inside libc scope, much smaller
- only asm files moved from previous attempt (overall around 400+- lines):
git apply --stat ../mc.patch repos/libports/lib/import/import-libc-context.mk | 1 repos/libports/lib/mk/libc.mk | 2 repos/libports/lib/mk/spec/x86_64/libc-context.mk | 9 + repos/libports/lib/symbols/libc | 2 repos/libports/ports/libc.hash | 2 repos/libports/recipes/api/libc_setjmp/content.mk | 2 repos/libports/src/lib/libc/dummies.cc | 28 +- repos/libports/src/lib/libc/patches/mcontext.patch | 346 ++++++++++++++++++++ 8 files changed, 387 insertions(+), 5 deletions(-)
https://github.com/tor-m6/genode/commit/b5ed6a49b0b6c09b20161b1ea726dbb685ae...
Also add test for them, see separate patch. Not yet choose where to put, potentially should be near makecontext() declaration inside libc include/libc/ucontext.h. extern "C" void *alloc_secondary_stack(char const *name, size_t stack_size);
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).
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.
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.
I hope this helps a little,
Sebastian
[1] https://github.com/tor-m6/genode/tree/21.02 [2] https://github.com/tor-m6/genode-world [3] world.patch [4] src.patch [5] alloc_secondary_stack.patch [6] src/lib/gcc/libgo/go/runtime/mem_gccgo.go