[PATCH 1/3] ntdll: For Mac 64-bit, poke the TEB address to %gs:0x30 and re-enable the inlining of NtCurrentTeb().

[Sebastian Lackner]

On 27.07.2016 18:30, Ken Thomases wrote:
> On Jul 27, 2016, at 11:08 AM, Sebastian Lackner <sebastian at fds-team.de> wrote:
>>
>> On 27.07.2016 17:42, Ken Thomases wrote:
>>> 64-bit Windows apps have hard-coded accesses to %gs:0x30 baked into them.  They
>>> need to find the TEB self pointer there.
>>>
>>> Technically, the gsbase register and the memory it points to belong to the
>>> pthread implementation on macOS.  It's used for the pthread TLS implementation.
>>> However, study of the sources and experimentation reveal that TLS slot 6
>>> (offset 0x30) is not currently used.  Furthermore, Apple has promised to not
>>> use that slot in the future.  So, we hijack it for our purposes.
>>>
>>> This removes the implementation of NtCurrentTeb() based on pthread_key_create()
>>> and pthread_set/getspecific().
>>>
>>> Signed-off-by: Ken Thomases <ken at codeweavers.com>
>>> ---
>>> dlls/ntdll/ntdll.spec      |  2 +-
>>> dlls/ntdll/signal_x86_64.c | 34 +++-------------------------------
>>> include/winnt.h            |  2 +-
>>> 3 files changed, 5 insertions(+), 33 deletions(-)
>>
>> Nice to hear that Apple agreed to keep that slot reserved. Would it make sense to
>> keep the NtCurrentTeb export neverthless, for compatibility with libraries compiled
>> against old Wine?
> 
> Hmm.  I don't know.  I hadn't considered it.  What sorts of libraries?  Did you have some use case in mind?  I guess I'd be surprised if there were such libraries around.
> 
> -Ken
> 

I'm not sure if there are any important examples, but all libraries / executables
compiled with the old Wine headers will have references to the NtCurrentTeb export.
If users should still be able to use any previously compiled code, it would be
necessary to keep them. Thats also why we decided to keep it in our Staging patchset.