[PATCH 3/3] ntdll: For Mac 64-bit, poke NtCurrentTeb()->ThreadLocalStoragePointer to the corresponding offset from %gs.

[Sebastian Lackner]

On 27.07.2016 20:25, Ken Thomases wrote:
> On Jul 27, 2016, at 12:53 PM, Sebastian Lackner <sebastian at fds-team.de> wrote:
>>
>> I have only two suggestions:
>> - gsbase_offset == 0 (key == i) could also be valid, so it would be useful to distinguish this case.
> 
> It can't be valid because that would put the TLS at the beginning of struct _pthread, but the ABI actually reveals the first couple of fields.  pthread_t is a typedef for __darwin_pthread_t which is a typedef for struct _opaque_pthread_t which is defined (not just declared) in the headers (/usr/include/sys/_pthread/_pthread_types.h in the 10.11 SDK) and is less opaque than its name would suggest.  Comments in the definition of struct _pthread in libpthread make note of the ABI compatibility factor.
> 
> In practice, the TLS array is at the end of the struct and I think Apple told us it has to be there.

When you are sure that this is always true you can start searching at (key + 1).

> 
>> - the logic could be moved to a helper function, for example using the init once mechanism
> 
> I suppose, but it will be called for the first thread before there's a chance of creating secondary threads.  So, there's no race.  Also, I haven't looked, but I'm not sure what thread setup has to have been completed before RtlRunOnceExecuteOnce() can safely be used.

It looks like RtlRunOnceExecuteOnce is not safe to use (keyed_event not initialized yet).
You could use pthread (like used before in init_teb_key), but probably moving to
a function is sufficient to improve code readability. By avoiding the heavily indented
code it would already look a bit less hacky. ;)

> 
> -Ken
>