bug-hurd
[Top][All Lists]
Advanced

[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)

Hi!

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

Attachment: pgpmdJvbo15A7.pgp
Description: PGP signature


reply via email to

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