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