X-Recipient: archive-cygwin@delorie.com X-Spam-Check-By: sourceware.org Message-ID: <48BDDD4E.CE7CE1E9@dessent.net> Date: Tue, 02 Sep 2008 17:41:50 -0700 From: Brian Dessent X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: why the strange stack stuf in cygwin? References: <1220387695.26680.ezmlm@cygwin.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin@cygwin.com Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.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/