[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 1/3] ntdll: For Mac 64-bit, poke the TEB address to %gs:0x30 and re-enable the inlining o
From:       Ken Thomases <ken () codeweavers ! com>
Date:       2016-07-27 16:53:54
Message-ID: 36AE2D94-08F9-40C4-B1F1-FBCAE0D12D3C () codeweavers ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]