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 <tho...@codesourcery.com>wrote: > Hi! > > On Fri, 3 May 2013 21:23:49 +0300, Fotis Koutoulakis < > fotis.koutoula...@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 <i...@google.com> > wrote: > > > > > On Tue, Apr 30, 2013 at 6:53 AM, Thomas Schwinge > > > <tho...@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."*
