Hi! On Fri, 21 Jun 2013 16:16:55 -0700 (PDT), Roland McGrath <rol...@hack.frob.com> wrote: > Split-stack is fundamentally incompatible with __hurd_threadvar_location et
Not fundamentally: if split-stack were properly integrated into glibc, our threadvar resolver could track back split-stack's initial_sp (where the threadvars live, I presume). But as split-stack is not generally implemented but currently only for x86 GNU/Linux, I suppose there's no real harm for GCC Go's usability when not having it implemented on x86 GNU/Hurd -- Ian? > al (and cthreads). We won't ever be able to use split-stack until we (We're not using cthreads anymore.) > change to a proper thread-pointer-based implementation > (i.e. segment-register based stuff for i386). Sure, that's what I meant to say in the paragraph where I pointed to <http://darnassus.sceen.net/~hurd-web/open_issues/glibc/t/tls-threadvar/>, and we're (slowly) working on that. Last time I worked on it was <http://news.gmane.org/find-root.php?message_id=%3c878vdyqht3%2Efsf%40kepler%2Eschwinge%2Ehomeip%2Enet%3e>, and I have not yet been able to follow up with that. (I also have implemented the *context functions within the current threadvar arrangement, which can at least work in some cases (all single-threaded, and with libpthread if the new stack to be used has our standard stack size); patch already in Debian glibc and to be posted to glibc upstream later on.) Grüße, Thomas
pgp7XU9943ByF.pgp
Description: PGP signature
