X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <COL101-W79024AA92CE55EAB8D8548E65F0@phx.gbl>
From: Jay <jay DOT krell AT cornell DOT edu>
To: <sthoenna AT efn DOT org>, <cygwin AT cygwin DOT com>
Subject: RE: why the strange stack stuf in cygwin?
Date: Tue, 2 Sep 2008 23:00:22 +0000
In-Reply-To: <1220387695.26680.ezmlm@cygwin.com>
References: <1220387695 DOT 26680 DOT ezmlm AT cygwin DOT com>
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id m82N1CDb031663


Is it the source code making the function calls that bothers you,
or the code size/perf bloat?

 If it is the source, just hide it with macros, like:

 #define foo /* existing thread local stuff */ 
 #define bar /* existing thread local stuff */ 

  typedef struct cygwin_threadlocals_t {  
    int foo;  
    int bar;  
  } cygwin_threadlocals_t;  

  /* Returns NULL under rare circumstances:  
     threads created before cygwin1.dll loaded ("3pp") plus low memory, combined;
     neither scenario alone returns NULL. The data will be allocated in 
     cygwin1!DllMain(thread attach), which isn't called for threads created before
    cygwin1.dll loads, returning FALSE under low memory. If not then, then on demand,
    which can fail due to low memory.
  */
  cygwin_threadlocals_t* _cygwin_get_thread_locals(void);  

   #define foo (_cygwin_get_thread_locals()->foo)  
   #define bar (_cygwin_get_thread_locals()->bar)  

  I can go through and make/build/test a complete patch if the approach is ok.  
  This is how msvcrt.dll uses thread locals.
  But again surely you considered that. ?

  If it is the resulting object code, well, yeah, I can see that.  
  It's what I asked -- to be faster than TlsGetValue.  

> Changing a keyword from __thread to __declspec(thread) doesn't really
> solve any problem.

  I understand merely changing __thread to __declspec(thread)  
  accomplishes nothing useful, just another compilation error.  

  I meant implementing __thread in gcc. 
  (actually briefly I was confused) 
  Which would generate code. Which would have to do something.. 
  The Visual C++ implementation is in between TlsGetValue and the existing
   cygwin implementation in size/perf. Around three instructions per
   reference, no function call. 

> What "generated code"?  You mean have gcc do this?  Feel free to submit 
> a patch to gcc to make this happen. 

 I might. 

> The tls implementation is not the reason why there is no native 64 bit

  I understand that gcc doesn't yet target IA64 or AMD64 Windows and
   that is a /large/ blocking factor. 
  There are patches out there for AMD64, but it isn't clear 
  they are of release quality (last I checked), and they aren't upstream I think. 

> FUD to assume that the mechanism used for the 
> 32-bit stack manipulation could not be adopted for 64-bit. 

   True that the top of the stack should work on other architectures. 
   But it still seems somehow yucky to me. 

> rather than making silly pedantic and empty arguments I'd rather that you
> contributed to making things better.  That is if you were truely up to it
> capable.

  I am capable of contributing changes. Agreement on what they should be is the hard part.

>  D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(140):        respawn_wow64_process (); 
> This has nothing to do with the "strange stack stuff" that you are 
> objecting to. 

 I don't yet know what it's there for, but it is vaguly also "strange stack stuff" 
 since it seems to not want the stack in a particular range. 

> If it makes you nervous don't use it.  Delete it from your system.  This 

 It seems the best way by far to use gcc on Windows. 
 Including active maintenance. 
 
- Jay

--
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/