next iteration of golang support attempt

[Alexander Tormasov]

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

result for 21.02 available here:
https://github.com/tor-m6/genode/commits/21.02
https://github.com/tor-m6/genode-world/commits/master

please, take a look here
https://github.com/tor-m6/genode-world/blob/master/src/test/go_app/README.golang

I used for my compilation command like
make -C build/x86_64/ KERNEL=nova CFLAGS="-g -O0" VERBOSE= run/go_app
before you need to make additional libs like written in README. I am not sure for 100% that I fix all problems, may be something still not works, please, report.

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)
  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...
  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).
  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.
  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)

Probably something else?

Sincerely,
    Alexander

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20210326/267e8166/attachment.html>