X-Recipient: archive-cygwin AT delorie DOT 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 AT cygwin DOT com Subject: Re: why the strange stack stuf in cygwin? References: <1220387695 DOT 26680 DOT ezmlm AT cygwin DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list 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/