Hi! On Wed, 15 May 2013 16:04:02 +0200, I wrote: > 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.
In fact, I implemented and (lightly) tested that three weeks ago, <http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=t/context_functions&id=018259d791f1ced4b2ced88c393cc74de15006ed>. Cleanup remaining to be done, if someone is interested: fix documentation bug in sysdeps/mach/hurd/i386/makecontext-helper.c (as a void function, makecontext can't actually return an error, deferring checking until setcontext/swapcontext would be clumsy, and their callers would very likely not be prepared to handle and recover from EINVAL or something), copy sysdeps/mach/hurd/i386/makecontext-helper.c into a libpthread sysdep directory, remove libpthread bits from sysdeps/mach/hurd/i386/makecontext-helper.c (or instead adjust for C threads, but probably not worth it). Anyway, Samuel, would you please put the current »tg patch t/context_functions« as a new patch into the Debian glibc package? Grüße, Thomas
pgp9cz_WQ9D_I.pgp
Description: PGP signature
