inline static pthread_t __attribute__((__pure__))
_pthread_self_direct(void)
{
       pthread_t ret;
#if defined(__i386__)
       asm("movl %%gs:%P1, %0" : "=r" (ret) : "i" (offsetof(struct _pthread, tsd[0])));
#elif defined(__ppc64__)
	register const pthread_t __pthread_self asm ("r13");
	ret = __pthread_self;
#endif
       return ret;
}

i think this is what you are looking for.

On Jan 9, 2015, at 12:18 PM, Ken Thomases <ken@codeweavers.com> wrote:

On Jan 9, 2015, at 6:01 AM, Maarten Lankhorst <maarten@mblankhorst.nl> wrote:

On 09-01-15 06:11, Ken Thomases wrote:

The Mac driver crashes in a 64-bit build for reasons I haven't investigated, so you have to use the X11 driver.  You can do this using WINEDLLOVERRIDES="winemac.drv=d" or by setting this in the registry after the prefix is created:

Doesn't win64 and mac64 both use the %gs register for TLS?

Yes, but this incarnation of Wine64 does not attempt to directly manipulate %gs.  My understanding is that it can't without a syscall, anyway.

Could that be related to the crash?

It could be, but I don't think it is in this case.

Certainly not since both our patches implement NtCurrentTeb() to use a pthread key to store the Thread Environment Block pointer instead of stuffing the pointer into the GSBASE MSR--which we really can���t do (as Ken said) without special support from the system. In any case, every part of Wine that accesses the TEB does so by calling NtCurrentTeb().

We're hoping that few actually do use %gs and, so, that they won't break.  We can't fix the problem

I���m not so sure about that, though I���m still waiting for Apple to release the source to their pthread stuff: in 10.9, they pulled it out of the kernel and into a kext, presumably so someone like me could replace it without replacing the whole kernel and use %fs instead of %gs for the pthread struct. (I can���t imagine any other reason they���d do that.) Then they closed my radar and told me they gave up on it, so I���m not holding my breath. I wonder how many pieces of the system other than the pthread kext and pthread library depend on %gs holding the current pthread pointer���

but maybe it won't actually matter much in the real world.  That's the purpose of this experiment: to find out if that's so.

Maybe it won���t, but my understanding is that copy protection software likes to reach directly into the TEB. That���s why we set up %fs to point to it on i386, and try to set up %gs on x86-64. Even if they called NtCurrentTeb() to get the TEB pointer, they won���t work here, because NtCurrentTeb() (in Microsoft���s headers and without either of our patches) dereferences the %gs segment register to get it. But hopefully you���re right, and such copy protection software is rare.

Chip