bug-hurd
[Top][All Lists]
Advanced

[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: Wed, 15 May 2013 16:04:02 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)

Hi!

On Fri, 3 May 2013 21:23:49 +0300, Fotis Koutoulakis 
<fotis.koutoulakis@gmail.com> wrote:
> A link to it can be found here:
> https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/nlightnfotis/1
> (I
> hope it is publicly visible, it seems to me it is).
> 
> Of course, I am more than open to comments/criticism as well as
> clarifications.

Your Estimated Project Timeline is not yet very specific (though I'm well
aware that this is difficult to do).  Replacing the (legacy) threadvars
mechanism with TLS shall not really be your project; yours is to port Go
(or more specifically, its runtime library) to GNU Hurd.

As an obvious preparatory task (which in a way is also present in your
Estimated Project Timeline, Before May 15): have you been able to
complete a build of GCC for/on GNU/Hurd, and (roughly) reproduced my
current test results, as per my notes on
<http://darnassus.sceen.net/~hurd-web/open_issues/gcc/>?  (Not for Go
yet, of course, but so that you generally have set up a suitable
development environment for GCC work.)  You can clone the hurd/web.git
repository from Savannah, and check out the toolchain/logs/master branch
(which I have as a Git submodule on toolchain/logs), and compare the
*.sum files in gcc/coulomb.SCHWINGE/test/ with those you get.

Ian, anything else we would like Fotis to do/provide at this time?


As for the roadblock:

> On Tue, Apr 30, 2013 at 4:58 PM, Ian Lance Taylor <iant@google.com> wrote:
> 
> > On Tue, Apr 30, 2013 at 6:53 AM, Thomas Schwinge
> > <thomas@codesourcery.com> wrote:
> > >
> > > 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.
> >
> > Go does require switching stacks.  A port of Go that doesn't support
> > goroutines would be useless--nothing in the standard library would
> > work.

I think I have found a way so that we can hack around that problem on the
Hurd/glibc side (that is, implement the setcontext et al. function in the
threadvars environment) until we're able to address the issue properly
(replace threadvars with TLS proper).  Not yet implemented and tested,
but I'm on it; slowly, time is limited.


Grüße,
 Thomas

Attachment: pgp6CYRu3D8ya.pgp
Description: PGP signature


reply via email to

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