[Top][All Lists]

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

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

From: Thomas Schwinge
Subject: Re: GCC's -fsplit-stack disturbing Mach's vm_allocate
Date: Sat, 22 Jun 2013 09:19:51 +0200
User-agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)


On Fri, 21 Jun 2013 16:16:55 -0700 (PDT), Roland McGrath <roland@hack.frob.com> 
> 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
and we're (slowly) working on that.  Last time I worked on it was
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.)


Attachment: pgpb7r8ghHpjt.pgp
Description: PGP signature

reply via email to

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