This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: why the strange stack stuf in cygwin?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]