[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inquiry about GCC Summer Of Code project idea.

From: Thomas Schwinge
Subject: Re: Inquiry about GCC Summer Of Code project idea.
Date: Tue, 30 Apr 2013 15:53:22 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)


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 <iant@google.com> wrote:
> On Mon, Mar 25, 2013 at 7:42 AM, Fotis Koutoulakis
> <fotis.koutoulakis@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.
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.


Attachment: pgpov5SphtCZt.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]