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. _______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
