X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Tue, 2 Sep 2008 11:19:00 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: why the strange stack stuf in cygwin? Message-ID: <20080902151859.GA7555@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <1220310319 DOT 16119 DOT ezmlm AT cygwin DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 On Tue, Sep 02, 2008 at 07:31:01AM +0000, Jay wrote: > > >[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. The tls implementation is not the reason why there is no native 64 bit support. There are many many issues involved in doing this, the most basic being that there is no cygwin gcc compiler which targets 64-bit Windows. Also it is FUD to assume that the mechanism used for the 32-bit stack manipulation could not be adopted for 64-bit. I assure you that given sufficient time, motivation, and a gcc compiler, Corinna and I are up to the task of porting Cygwin to a 64-bit system. >> [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? No, it isn't. There is a fundamental difference between littering the code with function calls to retrieve variable values and just using the variable normally in code. > Couldn't the generated code use TlsGetValue? What "generated code"? You mean have gcc do this? Feel free to submit a patch to gcc to make this happen. > Or that's considered too slow? > Or, even, do what Microsoft's __declspec(thread) does? Changing a keyword from __thread to __declspec(thread) doesn't really solve any problem. > 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." ? That should be self-evident without asking the question. What's the alternative? The Cygwin developers have never heard of TlsGetValue? If that was really the case then no one should be using Cygwin. We obviously don't get the fundamental concepts. >> (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. Cygwin is obviously going to be special. Other DLL don't try to implement fork or exec or deal with linux signals. >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. ? This has nothing to do with the issue. dlopen() works fine in Cygwin. The problem is that Cygwin is trying to duplicate the functionality of an operating system so it does a lot of things which make it hard to load dynamically. The tls implementation is only one of many things that don't work well. >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. You really need to do your homework if you want to discuss these issues. >>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 (); This has nothing to do with the "strange stack stuff" that you are objecting to. >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. If it makes you nervous don't use it. Delete it from your system. This is especially true if you think that people who wrote a complicated system with many thousands of lines of code need simple advice like "just use TlsGetValue". cgf -- 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/