Re: [PATCH 1/3] ntdll: For Mac 64-bit, poke the TEB address to %gs:0x30 and re-enable the inlining of NtCurrentTeb().
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@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?
On Jul 27, 2016, at 11:08 AM, Sebastian Lackner sebastian@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@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
On 27.07.2016 18:30, Ken Thomases wrote:
On Jul 27, 2016, at 11:08 AM, Sebastian Lackner sebastian@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@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.
On Jul 27, 2016, at 11:38 AM, Sebastian Lackner sebastian@fds-team.de wrote:
On 27.07.2016 18:30, Ken Thomases wrote:
On Jul 27, 2016, at 11:08 AM, Sebastian Lackner sebastian@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@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.
Previously compiled code other than Wine itself, right? I.e. winelib apps. Which call NtCurrentTeb(). Built for Mac 64-bit. I guess I don't think that's an important case, but if others disagree I can change the patch.
-Ken
-
Ken Thomases -
Sebastian Lackner