[set,get,make,swap]context from glibc for amd64 implementation and question for Norman

[Alexander Tormasov]

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.