Mail Archives: cygwin/2008/09/02/11:19:55
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/
- Raw text -