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

[Sebastian Sumpf]

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