Make the Google Go programming language available on GNU/Hurd in its GCC gccgo implementation, and enable Hurd-specific features.

There is a FOSS Factory bounty (p263) on this task.


Part I

First, make the language functional, have its test suite pass without errors.

Original GSoC Task Description

The goal of this project is to make the Google Go programming language available on GNU/Hurd in its GCC gccgo implementation.

Presumably less work will be needed on the language's frontend itself, but rather on the supporting libraries.

Apart from a solid knowledge of the ?POSIX API, working knowledge of the Google Go programming language is a must. Some Hurd knowledge will have to be acquired while working on the project.

Designing and implementing language bindings is a follow-up project.

Possible mentors: Ian Lance Taylor: gccgo bits, Thomas Schwinge (tschwinge): Hurd bits.

Exercise: Fix one of the problems preventing gccgo from working on the Hurd.


Open Issue page. Entry in the GCC wiki.

Posted 2011-04-26 22:00:06 UTC

Svante's work

Per id:"1335509732.3707.179.camel@hp.my.own.domain", Svante has been working on this, has some (unpublished) patches, and this is currently blocked on getcontext/setcontext.

getcontext/makecontext/setcontext/swapcontext usage analysis

In context of tls-threadvar. Looking at GCC trunk commit f6568ea476aa52a6e23c6db43b3e240cde55783a (2013-04-26).

The check in libgo/configure.ac whether setcontext clobbers TLS variables is invalid on GNU Hurd.

The *context functions are used in libgo/runtime/go-signal.c and libgo/runtime/proc.c.

__splitstack_getcontext, __splitstack_setcontext, __splitstack_makecontext, __splitstack_resetcontext, __splitstack_block_signals_context are to be provided by libgcc. However, in said libgo runtime files, they're used only #ifdef USING_SPLIT_STACK. ?I would assume that before we can enable split stacks, first tls-threadvar needs to be fixed.

In libgo/runtime/proc.c:runtime_gogo, setcontext is used to switch context to a different goroutine. TODO.

In libgo/runtime/proc.c:runtime_mcall, which save[s] context and call[s] fn passing g as a parameter, getcontext and setcontext are used; this is only called from libgo/runtime/proc.c:runtime_gosched. TODO.

In libgo/runtime/proc.c:runtime_tracebackothers, getcontext is used to switch context to the goroutine. TODO.

In libgo/runtime/proc.c:runtime_mstart, which is called to start an M, getcontext is used. TODO.

In libgo/runtime/proc.c:runtime_entersyscall, which is called when the goroutine g is about to enter a system call, getcontext is used to save the registers in the g structure so that any pointers held in registers will be seen by the garbage collector. Should be fine.

In libgo/runtime/proc.c:__go_go, getcontext and makecontext are used. TODO.

In libgo/runtime/thread.c:runtime_minit, which is [c]alled to initialize a new m (including the bootstrap m), ss.ss_sp is set to a new stack retrieved via libgo/runtime/proc.c:runtime_malg, which allocate[s] a new g, with a stack [...], and then sigaltstack is called. TODO.

libgo/runtime/go-signal.c:  /* We are now running on the stack registered via sigaltstack.
libgo/runtime/go-signal.c:     and sigaltstack when the program starts.)  */

libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_sp = vsp;
libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_sp += vspsize;
libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_size = vspsize;

Also, in libgo/runtime/proc.c:runtime_newm, pthread_attr_setstacksize is used, which we also can't support yet, for the same reason.


Part II

Next, Hurd-specific features can be added. Add an interface to the language/environment for being able to do RPC calls, in order to program translators natively in the Google Go programming language.

Original GSoC Task Description

The main idea of the Hurd design is giving users the ability to easily modify/extend the system's functionality (extensible system). This is done by creating filesystem translators and other kinds of Hurd servers.

However, in practice this is not as easy as it should, because creating translators and other servers is quite involved -- the interfaces for doing that are not exactly simple, and available only for C programs. Being able to easily create simple translators in RAD languages is highly desirable, to really be able to reap the advantages of the Hurd architecture.

Originally Lisp was meant to be the second system language besides C in the GNU system; but that doesn't mean we are bound to Lisp. Bindings for any popular high-level language, that helps quickly creating simple programs, are highly welcome.

Several approaches are possible when creating such bindings. One way is simply to provide wrappers to all the available C libraries (libtrivfs, libnetfs etc.). While this is easy (it requires relatively little consideration), it may not be the optimal solution. It is preferable to hook in at a lower level, thus being able to create interfaces that are specially adapted to make good use of the features available in the respective language.

These more specialized bindings could hook in at some of the lower level library interfaces (libports, glibc, etc.); use the MIG-provided RPC stubs directly; or even create native stubs directly from the interface definitions. The lisp bindings created by Flavio Cruz as his 2008 GSoC project mostly use the latter approach, and can serve as a good example. In his 2011 GSoC project, Jérémie Koenig designed and began implementing an object-oriented interface; see his Java status page for details.

The task is to create easy to use Hurd bindings for a language of the student's choice, and some example servers to prove that it works well in practice. This project will require gaining a very good understanding of the various Hurd interfaces. Skills in designing nice programming interfaces are a must.

Anatoly A. Kazantsev has started working on Python bindings last year -- if Python is your language of choice, you probably should take his work and complete it.

There was also some previous work on Perl bindings, which might serve as a reference if you want to work on Perl.

Possible mentors: Anatoly A. Kazantsev (anatoly) for Python

Posted 2009-03-05 18:20:56 UTC