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 <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. It might be possible to use pthread_getspecific and > friends > instead of TLS. > > Ian > > > > > -- > Fotis 'NlightNFotis' Koutoulakis > > > - "Non semper aestas erit; venit hiems." >
