X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <COL101-W14D48F9003108712214BA3E65F0@phx.gbl>
From: Jay <jay DOT krell AT cornell DOT edu>
To: <cygwin AT cygwin DOT com>
Subject: Re: why the strange stack stuf in cygwin?
Date: Tue, 2 Sep 2008 07:31:01 +0000
In-Reply-To: <1220310319.16119.ezmlm@cygwin.com>
References: <1220310319 DOT 16119 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 m827W1rd023093


 >[jay] harder to port to other architectures,
> [cgf] Cygwin works on all of the architectures that Windows NT+ supports.


 I mean really doing a native AMD64 and/or IA64 port, not just relying  
 on the ability to run 32bit x86 code. Imho, that's cheating. 


> [jay] Why does Cygwin do such wierd stuff with the top of the stack? 
> [jay] Is this to have thread locals faster than TlsGetValue offers? 


 [cgf] No, it is a work-around for this: 

 [cgf]   % cat <<'EOF'> foo.c 
 [cgf]   __thread int abc; 
 [cgf]  
 [cgf]   int 
 [cgf]   main (int argc, char **argv) 
 [cgf]   { 
 [cgf]     printf ("%d\n", abc); 
 [cgf]   } 
 [cgf]   EOF 
  
 [cgf]   % gcc -o foo foo.c 
 [cgf]   foo.c:2: error: thread-local storage not supported for this target 

 Isn't that what I said? 
 Couldn't the generated code use TlsGetValue? 
 Or that's considered too slow? 
 Or, even, do what Microsoft's __declspec(thread) does? 
 Granted, __declspec(thread) doesn't work pre-Vista if you are loaded with LoadLibrary,
   or is __declspec(fiber) provided as you might actually want.
 At least with TlsGetValue, it is easy to switch to FlsGetValue, though that requires post-XP.

> Is it worth it?

 [cgf] What kind of answer do you expect here?  A head slap and a "What were we
 [cgf] thinking???"

Maybe "Yes it is gnarly and complicated, but it's all we have so far." ?

> (The cost: harder to LoadLibrary(cygwin1.dll),

 [cgf] Dynamic linking of cygwin1.dll (i.e., making it easier to be a 3PP) has never 
 [cgf] been a core goal of Cygwin. 

 3PP? ok, I found it.
 Huh. Pretty much all .dlls work with LoadLibrary.
 Cygwin1.dll is a wierd exception.
 Granted, I can see that in its problem space, it might not be interesting.
 Since LoadLibrary is probably used much more often in Windows code than
  the corresponding dlopen is used in Unix.
 And, I kinda thought that the difficulty of using LoadLibrary on cygwin1.dll
  applied transitively to any .dll using cygwin1.dll, but I haven't verified that.
 And still, maybe not interesting for the reason I gave. Still odd though.

>the strange path where DllMain "respawns", etc.) 

> [cgf] "the strange path"? 
> [cgf] You're using shorthand which assumes that people understand your thought  

   Searching for 'respawn'...  
  D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(69):respawn_wow64_process ()  
  D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(92):  /* The parent is a real 64 bit process?  Respawn! */  
  D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(136):	 spawned by a genuine 64 bit process.  If so, respawn. */  
  D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(140):	respawn_wow64_process ();  

  The code seems very wierd in places.  
  I don't "like" it.  
  I know, boo hoo, whine whine whine. It seems to work but it makes me nervous.  
 

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