Re: Inquiry about GCC Summer Of Code project idea.

[Fotis Koutoulakis]

Hello Thomas,

First of all, I would like to thank you for your feedback. It means a lot to me.

> 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.

I do understand this, but if you believe this would not take me out of my schedule,

I would like to attempt this, as I am given the impression that this is important for the HURD.

If you believe it would be too hard to do this along with the main assignment, I could scrap it 

if there would be a viable work around - or if you believe it's beyond my skills.

> 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

Yes, I am on it. Not yet finished, but I am very close to have a working environment on top of Debian GNU/HURD.

> 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.

Again, since my first assignment is to port the go frontend to the HURD, I could use that work around.

However, keep in my mind, that my objective is not do simply "do something", I want to do useful work,

so unless I am seriously time constrained, I would like to help advance the HURD 

by doing some infrastructure work on it.

Last but not least, I would like to know if you have some other proposition for me. Mr Ian could have a suggestion for the go part perhaps?

Thank you for your feedback - it means a lot to me.

Fotis Koutoulakis.

On Wed, May 15, 2013 at 5:04 PM, Thomas Schwinge <thomas@codesourcery.com> wrote:

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

--

Fotis 'NlightNFotis' Koutoulakis

- "Non semper aestas erit; venit hiems."