[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inquiry about GCC Summer Of Code project idea.
From: |
Svante Signell |
Subject: |
Re: Inquiry about GCC Summer Of Code project idea. |
Date: |
Fri, 03 May 2013 23:29:38 +0200 |
Hi Fotis,
I finally found my changes made so far for gccgo on a computer suffering
double hard disk crashes. Hopefully most of the changes are available on
the backup I found. As it looks they were not too extensive. I'll send a
patch asap to the bug-hurd list, so you can continue from there (when
you are accepted by Google/GNU)
Good luck,
Svante Signell
On Fri, 2013-05-03 at 21:23 +0300, Fotis Koutoulakis wrote:
> Hello!
>
>
> First of all I would like to thank you everyone for your input. I
> really appreciate it.
>
>
> I would also like you to know that I managed to study the material
> that you all have linked to (or that is generally available online on
> the project's wikis of that matter) and I managed to come up with a
> proposal for the project idea that got me hooked in the beginning.
>
>
> 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.
>
>
> Last but not least, I would like to thank you all for your time, as
> well as grab the chance to apologize for my late proposal and my late
> answer.
>
>
> Sincerely,
> Fotis Koutoulakis
>
>
> 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. It might be possible to use pthread_getspecific and
> friends
> instead of TLS.
>
> Ian
>
>
>
>
> --
> Fotis 'NlightNFotis' Koutoulakis
>
>
> - "Non semper aestas erit; venit hiems."
>