Hello Alexander,
as predicted I am back with some questions.
First, thanks for your efforts of bringing Golang to Genode. I took a look at the commits on your topic branch and your README was very helpful in getting started; especially the current limitations section reflects questions I am going to ask. Please bear with me if some questions sound obvious but I lack the understanding of the inner workings of Golang's run-time and I did not follow all your previous E-Mails on the ML.
So, I checked out your 20.11 branch and tried to follow your instructions. Unfortunately, I could not compile libgo out-of-the-box because libtool was complaining about “unrecognized options” and I stopped at this point.
This brings me to my first question
* Is there a technical reason for executing the auto-tools build system rather than porting the libraries, i.e., create the .mk files for Genode's build system?
The instructions in the README lack the motivation behind that decision.
and furthermore
* Is it strictly necessary to solely produce static libraries or could we get away with a dynamic shared-object, libgo.lib.so, that incorporates everything and the target application is linked against or is it possible to have multiple shared-objects. After all, there is already a libffi port - ffi - that is built as .lib.so.
While stepping through the libgo commit I noticed the patches:
* You choose to add a new run-time target, “inno”, that is based on NetBSD rather than using the existing FreeBSD target. For all intents and purposes, Genode appears to be FreeBSD for ported software due to using its libc¹. Is there a reason why that is not possible for Golang's run-time?
IIRC, on some platforms, e.g. Solaris(?), the normal Golang run-time solely uses the libc to interface with the OS instead of wrapping system-calls directly. Is it the same with gccgo's run-time?
With regard to the first questions, if we remove auto-tools from the equation we could shadow specific run-time parts where the upstream implementation does not work on Genode.
¹) Granted, our libc port is not feature-complete and might lack expected functionality, e.g. kqueue/sysctl or as you already noticed mmap handling, but we could take this as an opportunity to extended our libc port.
* I noticed that you use internal headers for implementing the stack handling. Is in this context the available Genode::Thread API not enough?
My somewhat naive point of view would be to use our POSIX layer wherever possible and only diverge where necessary - that only boils down to go-routine and stack handling or does it not?
Finally, the most important question:
* From what I can tell the port itself still somewhat feels like a proof-of-concept that as you mentioned in the README is the side result of a research project. It would require further clean-up before we could add it to Genode.
(This includes the current short-comings like missing context support for go-routines, reliance on -fno-omit-framepointer, etc. The support code that is currently part of the component should be moved to a central location like you already suggested.)
Would you be willing to do that clean-up work or is it from your point of view enough to just keep the port as an example in case somebody else wants to do that? Your reaction so far, creating the github issue, suggest that you do have some motivation.
I ask because in the past we got a welcome one-time contribution for Rust support on Genode. However, since we do not use Rust, we merely dragged it along and eventually removed it². As support for Golang has no immediate priority for us, we hesitate to spend our limited time on this at the moment.
That being said, I wrote our CI-tools web front end in Golang and running it on Genode certainly would be nice and could be a reason to nonetheless set some time aside to get that up and running :-). Judging by the reaction on your issue, we could very well make a community effort out of supporting Golang.
²) To not make the same mistake I imagine adding support to our tooling for creating Golang based components is necessary. Maybe it is worthwhile to extend 'goa'[sic] in that regard so that a Golang-developer can use 'go' to initially develop his or her application and later one use 'goa' to create a binary for Genode, while 'goa' does the heavy-lifting behind the scenes. I think you briefly touched the “go build → Makefile” topic in one of your mails. After all, rather than writing specific Genode components in Golang I guess people want to deploy their existing applications first and would be fine with interacting with Genode via the POSIX/VFS layer.
Regards Josef