On 3/24/21 9:22 AM, Alexander Tormasov via users wrote:
So in case of go, the libgo library should be linked against such an support library, that - as it uses the Genode API - needs to be linked against the Genode base library. If that is not possible, presumeably because adding additional libraries to libgo's build-system is cumbersum, linking your go component against the library should do the trick.
libgo.a is not a shared library, so, it just can be linked to application directly together with mcontext.a library, should not be a problem
It goes without saying that this approach only works if you are fine with linking against the base library but I think for the time being
probably fine - except that I still have a problem in moving anon_mmap support from libc to separate library. Problem that I need kernel heap reference from Libc::Kernel instance which is somehow private. Seems that I can’t just call Kernel heap allocator (need for metadata store inside anon_mmap), and I should patch file_operations.cc http://file_operations.cc to expose reference to _heap via some function.
I think you could use the 'Libc::Allocator' (libports/include/libc/allocator.h) or a simple 'malloc' in 'map_anon' instead of the heap.
Sebastian