> > The second problem is that libpthread relies on %gs
> remaining unchanged. For
> > Wine, this would mean that we'd have to save %gs during
> 16-bit calls (and
> > restore it in signal handlers if necessary). This would be
> easy to do. But,
> > even 32-bit code might conceivably modify %gs under
> Windows; this would
> > be problematical ...
>
> It shouldn't be too much of a problem since we wouldn't use pthreads
> functions except for thread creation; so basically we would need to
> restore %gs only when calling libc functions that might use pthreads
> routines, and in signal handlers.
That will work fine for the emulator.
It will also work fine for a WineLib
application that only calls the Windows API.
However if somebody gets the idea that he should
adds some Linux specific functionallity to the
his working WineLib application he might get a crash
since gs might not have the correct value.
This is not what we want. Of course this is only
a problem is the WineLib application uses gs,
which is not very likely in itself.
However it might use a Windows binary only dll
that does...
Besides having to add case by case save/restore
gs code in the Wine source is very error prone
and new/different versions of libc might have
new/different functions using pthreads.
Of course doing it in a thunking layer
as proposed by Ulrich (and I) is not
very cheap runtime wise, but it is obviously
correct and much more maintainable and the
thunking layer is needed for running x86
binaries on non-x86 anyway.
Note that once the thunking layer is inplace we could
have compile time options that made Wine/WineLib run
faster is the application only called Windows API functions.
In short we could do both as you and Ulrich (and I)
proposed and have compile time options and let
the user decide between speed, Windows API only
and using things like OpenGL the needs pthreads.
However as I said I'm not sure I like your
approach at all, since it is error prone.
