bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

setcontext et al. functions (was: Inquiry about GCC Summer Of Code proje


From: Thomas Schwinge
Subject: setcontext et al. functions (was: Inquiry about GCC Summer Of Code project idea.)
Date: Tue, 11 Jun 2013 10:27:09 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)

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

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

Attachment: pgpk0jiAIgBhz.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]