On Fri, 24 Jan 2003, Ulrich Weigand wrote: [...]
This means that C source code compiled against the new headers will result in assembler code that *directly* accesses a thread-local variable as defined by the TLS ABI. In the case of errno, this will involve accessing the %gs segment using an offset from the GOT, without any function call being performed. (errno is defined to use the initial-exec TLS storage model.)
I probably only have a limited understanding of these threading problems. However I had an idea and this limited knowledge lead me to believe that it might work and so now I have to inflict it on the world<g>.
So basically the problem as I understand it is that both Linux libraries and some Windows applications believe that the %gs register points to a TLS structure, except that these two structures are not compatible.
Hmmm, wait a minute, could they be made compatible? E.g. by changing the struct definition in glibc? Anyway, assuming that's not possible...
So we basically need separate values for this register for the Windows code and the Linux code.
So why not save and restore that register whenever we enter and exit a builtin dll?
It seems that it should be pretty easy to modify each DLL entry point to do:
{ wine_restore_linux_gs(); ... wine_restore_windows_gs(); return ret; }
Of course, the DLL entry points are the easy part. The hard part is:
* modifying all code that invokes a callback function to first restore the windows %gs and the linux one when the call returns * modifying all builtin callback functions to do the same as entry points * modifying all COM functions
Well, now I will let people who know better explain why this cannot work :-)