Hi! I'm sorry for the late answer. Ian, there's a question for you towards the bottom of the email.
On Mon, 25 Mar 2013 08:22:15 -0700, Ian Lance Taylor <i...@google.com> wrote: > On Mon, Mar 25, 2013 at 7:42 AM, Fotis Koutoulakis > <fotis.koutoula...@gmail.com> wrote: > > > > I am writing this email with regard to a potential project idea that's > > hosted on the GCC wiki about porting the go programming language GCC > > (gccgo) frontend to the GNU/HURD operating system (information found > > here-> http://gcc.gnu.org/wiki/SummerOfCode and here-> > > http://www.gnu.org/software/hurd/open_issues/gccgo.html). > > > > My specific queries would be: > > > > - This particular idea seems to be eligible for this year's Google > > Summer Of Code. Further research on the GCC wiki shows that this > > particular idea has never been implemented in the past - or assigned. > > However, I would like someone else to assert my assumption that this > > is eligible for this year's GSOC. > > Yes, it is eligible. > > (This is of course no guarantee that this particular project will be > selected. It depends on the other proposals we receive.) As you can see on <http://darnassus.sceen.net/~hurd-web/open_issues/gccgo/>, Svante has been working on this (outside of the GSoC context), but has not yet published his patches. (And yet if he did, I'm condfident there'd still be enough work left for a GSoC project: (continue) porting Go's runtime library, language/RPC bindings, etc.) > > - What would be the specific educational and knowledge background that > > the student who wishes to implement this particular idea should have? > > I can see mentions of good POSIX API knowledge, go language knowledge > > and HURD knowledge here, but I would like to know if there would be > > more requirements regarding this specific project idea that are not > > immediately obvious. > > I think you're pretty much right. I think the most important part > coming in would be a clear understanding of the HURD, its system call > interface, and its object file format. You would have to be able to > dig into the Go library, to understand how implements the system call > layer. Yep. As for understanding of the Hurd, as long as the project doesn't shift towards the language/RPC bindings, not really too much Hurd internals should be needed -- use the standard POSIX interface as exported by glibc. > > - What would be a skill level estimate for someone wishing to try this > > project in an attempt to get his feet wet in compiler engineering? > > Unfortunately it's hard for me to judge. The most important skill > would be the ability to dig into some large code bases and understand > how to change them. Agreed, and as Samuel already followed up, this is not a project that will require you to know compiler theory proper, or its implementation. On <http://darnassus.sceen.net/~hurd-web/open_issues/gccgo/> I have just updated/posted a getcontext/makecontext/setcontext/swapcontext usage analysis. This might constitute a "road block": the Hurd currently does not allow for changing the stack of a process/thread. Implemented a while before TLS/__thread variables came along, we have a legacy threadvar mechanism implemented in glibc, which places thread-local variables (errno, for example) at the bottom of a thread's stack. Then, when switching the stack of a thread, glibc can't locate these anymore, and "bad things" happen. This threadvar mechanism is scheduled to go away (we do implement TLS by now), but when working on that I hit "some issues" and have not yet found the time to continue. <http://darnassus.sceen.net/~hurd-web/open_issues/glibc/t/tls-threadvar/> and <http://news.gmane.org/find-root.php?message_id=%3c878vdyqht3%2Efsf%40kepler%2Eschwinge%2Ehomeip%2Enet%3e> have the details. Now, it seems the GCC Go port is implemented in a way that makes extensive use of switching stacks. So until this threadvar issue is resolved, there is probably no way to really proceed with the GCC Go port for GNU Hurd -- unless maybe this stack switching could be hacked around (Ian?), say, by limiting oneself to not using Goroutines and similar "specials", and having a custom/minimal Go runtime startup. Grüße, Thomas
pgp_AuxlXLLev.pgp
Description: PGP signature
