next iteration of golang support attempt

[Josef Söntgen]

Hello Alexander,

I am going to focus on your most recent E-Mail as the list at the end
also covers most of the question of the previous one.

> I finalise move of mcontext and libgo_support libraries, as well as update
> libgo a bit to reflect changes, and fix go test application.

> […]

Thanks, I used your branches and could successfully run the test component.
I then took both your branches and refactored the code somewhat [1], [2].
In the end adding support for building .go files with the Genode build-system
is all that is left in the Genode repository.

 [1] https://github.com/cnuke/genode/commits/golang-2021-03-29
 [2] https://github.com/cnuke/genode-world/commits/tor-m6-master-2021-03-26--golang

The world repository now contains all the support code that is needed in the
'libgo_support' library at the moment. The library is only made available for
x86_64 to make it clear it is the only support architecture.
Please take a look at my commits - I am not entirely sure if the local anon mmap
registry is “safe” to use but at least the test component seems to be fine.


> I need to understand what to do with unclosed questions to move further.
> May be you can add something below.
> I need to prioritise this list as well, this order is somehow random.

>   1.  fix SMP support
> (now it work only with 1 CPU, 2+ CPU give «deadlock ahead» err)

You should see the address of the mutex in question that leads to the
deadlock situation.

>   2.  fix debugging
> latest version do not normally start debug process with go_app_gdb.run,
> somewhere in the start of the go program in gogo() function log say
> [init -> gdb_monitor] upgrading quota donation for PD session (0 bytes, 4 caps)
> [init] child "gdb_monitor" requests resources: ram_quota=0, cap_quota=4
>  and hangs afterward, changes in number of caps in run file do not helps. I
> don’t find a way to print current cap quota yet...

I am not well versed in the ways of the gdbserver, maybe Christian Prochaska
wants to pitch in?

>   3.  create makefile for libgo and related libraries as static from the
> listing of compilation, as you suggest.
> Still not for 100% sure that this is worth do do - it will require periodic
> update, will have different set of files for different platforms, and not clear
> what to do with generated files (like .h for headers and .go for syscall/etc
> stubs) - whether it also should be generated once (like I do for mcontext now)
> or it worth to run via support scripts generated by configure. Also it is not
> clear how to add these generated scripts for port - should they appears as a
> patch file for main sources in contrib/* tree or it should be inside more local
> places like libgo_support in repos/world (then it will be complex mix of
> internal files and headers only for compilation of them and the rest - not so
> suitable for other usage of libgo_support).

By now we we keep such generated files in a different repository that is
referenced in the .port file and those files should be only generated by
the developer. The generated files are then stored in the contrib directory
of the port.
Of course they could be generated on the fly while preparing the port - we
do that for a number of ports - but that requires everyone to have the needed
host tools installed and depending on the version of the tools leads to
slightly different files which in return lead to different hashes in the
archive recipes. The scripts or the mechanism could still be part of the
.port file or could be stored in the repository for the generated files
depending on how extensive it is.

The library .mk files are in part responsible to assemble the contrib sources
properly for each platform or architecture.


>   4.  port to seL4.
> Now I can compile, some problems with kernel.s file - but it works with total
> recompilation. I see a problem that for nova and sel4 we could have different
> object files in common tree (e.g. because of different offsets of internal
> os-specific headers), not sure how to handle it, e.g. in libgo stubs for C OS
> interfaces.

I am not sure which OS specific headers that would involve but normally we try
to make the components as kernel-agnostic as possible. Of course there are
differences, like the virtual address-space layout differs between kernels,
but such things are enclosed and abstracted away by ld.lib.so. Now it could
be different for a language runtime in which case I am curious which
functionality that is?


The remaining points primarly deal with missing features where I have not
much to comment - IIRC Gapfruit has already worked on TCP support.

>   5.  port to arm64 for nova/etc.
> Need to create a mcontext staff (hopefully that it relatively easy)

>   6.  fix signals processing in mcontext
> now I completely omit call to SIG_MASK set/reset in the code, not sure which
> applications will have a problems

>   7.  check Go support for wider set of features
> like floating point, os interfaces, etc, including cleanup of stubs in libgo
> related to unused OS features from other subsystems (see README for list of
> broken calls)

>   8.  add golang support for TCP network
> need not only patch back some .go code, but also a set of sample .run files
> and test examples for configuration

>   9.  port feature which allow to generate make file from «go build» process
> in this moment go build and related compilation infrastructure not supported,
> I use gccgo

>   10. start port of docker libraries to Genode in the same way as it was done
> by me for another microkernel before (kind of complex task requiring some
> additional workforce support)


Regards
Josef
-- 
Josef Söntgen
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20210329/0255ba74/attachment.sig>