This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: why the strange stack stuf in cygwin?
- From: Brian Dessent <brian at dessent dot net>
- To: cygwin at cygwin dot com
- Date: Tue, 02 Sep 2008 17:41:50 -0700
- Subject: Re: why the strange stack stuf in cygwin?
- References: <1220387695.26680.ezmlm@cygwin.com> <COL101-W79024AA92CE55EAB8D8548E65F0@phx.gbl>
- Reply-to: cygwin at cygwin dot com
[ Your messages would be a lot easier to read without the random
schizophrenic line length and indentation. ]
Jay wrote:
> I meant implementing __thread in gcc.
Starting in 4.3 gcc supports emutls, which enables __thread support on
all threaded targets, even when there is no actual TLS support. It does
this by mapping accesses to the gthread API in libgcc, i.e.
__gthread_{get,set}specific. This is a generic API that maps onto one
of several platform specific thread APIs. In the case of Cygwin this is
pthreads, i.e. Cygwin defaults to --enable-threads=posix. This means
the accesses will go through pthread_{get,set}specific().
Obviously this is not usable from inside Cygwin, but otherwise it should
work fine.
> they are of release quality (last I checked), and they aren't upstream I think.
That's not true. The x86_64 MinGW target is fully functional in FSF gcc
and binutils. I don't know if it can bootstrap itself yet or is still
limited to crosses, but it's at the point where the output is usable at
least.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/