Re: GCC's -fsplit-stack disturbing Mach's vm_allocate

[Thomas Schwinge]

Hi!

On Fri, 21 Jun 2013 16:16:55 -0700 (PDT), Roland McGrath <roland@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

pgpb7r8ghHpjt.pgp
Description: PGP signature