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--gola...
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.
- 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.
- 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?
- 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.
- 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.
- port to arm64 for nova/etc.
Need to create a mcontext staff (hopefully that it relatively easy)
- 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
- 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)
- 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
- 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
- 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