Hello, Where would you find information on wine64 status for running 64 bit windows software under OSX. These days a lot of Windows programs are going 64bit to make use of the available memory. Its becoming necessary to have this capability. Many thanks Kevin
On Wed, Feb 19, 2014 at 01:43:17PM +0000, Kevin Davies wrote:
Where would you find information on wine64 status for running 64 bit windows software under OSX.
Information about Wine's 64-bit support and how to build it is here: http://wiki.winehq.org/Wine64 There is some information about building Wine on OSX here: http://wiki.winehq.org/MacOSX/Building And some information about using Wine and installing binary packages here: http://wiki.winehq.org/MacOSX You could also consider asking the binary package maintainers to provide a 64-bit version of Wine, if they don't already. Andrew
Am 20.02.2014 um 14:18 schrieb Andrew Eikum <aeikum(a)codeweavers.com>:
On Wed, Feb 19, 2014 at 01:43:17PM +0000, Kevin Davies wrote:
Where would you find information on wine64 status for running 64 bit windows software under OSX.
Information about Wine's 64-bit support and how to build it is here: http://wiki.winehq.org/Wine64
There is some information about building Wine on OSX here: http://wiki.winehq.org/MacOSX/Building
And some information about using Wine and installing binary packages here: http://wiki.winehq.org/MacOSX
You could also consider asking the binary package maintainers to provide a 64-bit version of Wine, if they don't already. Neither of those links answers Kevin’s question about the status of 64 bit support on OSX.
I don’t know the exact details myself (Ken is the expert), but the answer is that it does not work, and probably never will. OSX has a ABI incompatibility with Win64 - OSX overwrites a CPU register that Win64 applications expect to remain untouched. Apple can’t change the ABI because there are already 64 bit OSX apps that expect things to work that way. A potential workaround may be to run Wine inside a CPU emulator like qemu, but that is anything but easy.
On Feb 20, 2014, at 7:28 AM, Stefan Dösinger wrote:
I don’t know the exact details myself (Ken is the expert), but the answer is that it does not work, and probably never will. OSX has a ABI incompatibility with Win64 - OSX overwrites a CPU register that Win64 applications expect to remain untouched. Apple can’t change the ABI because there are already 64 bit OSX apps that expect things to work that way. A potential workaround may be to run Wine inside a CPU emulator like qemu, but that is anything but easy.
Actually, Alexandre is the expert, but this is my understanding as well. Besides running under an emulator, it may be possible to wrap every call out to system libraries with code to save and restore the register. Or, if you prefer to think of it this way, the wrapper would be on exit from and entry back into native Windows binary code. This would be somewhat similar to what we do with stack alignment, although we have compiler help for that. Either way, that would probably impose a significant performance penalty. -Ken
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-20 17:20, schrieb Ken Thomases:
Besides running under an emulator, it may be possible to wrap every call out to system libraries with code to save and restore the register. Or, if you prefer to think of it this way, the wrapper would be on exit from and entry back into native Windows binary code. This would be somewhat similar to what we do with stack alignment, although we have compiler help for that. Either way, that would probably impose a significant performance penalty. Sounds much more pleasant than an emulator. But doesn't the problem also affect multitasking context switches?
I have some llvm work (__ms_hook_prologue__) on my todo list anyway. Maybe it's an idea to add a compiler feature to take care of this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTBmkoAAoJEN0/YqbEcdMwktIP/11AS7Dv48LWFM+cmwVkWtld H7mHGe5Az6AYk8LeAfqXyA+tgk9MUtir8TQXZV3/6dAzLysf9kKDrikTPrSuqe8x IhJyNPz5asiMDHwzUJLTkXoaefLPZYDIzEu8Ce0VuBOwiprK4CXdv2b43p3E+hyU v5ERW0n01UBnQSKwDBwe60baRp7ToFv1BxNBATpidNZBdBIcKGpuqMVn2/nPytow GSytIVEFTlnE7d+DiQnzANyiOUVbeM8mjkHNJGTaYi9xD/WrPksA7ZZw8RIZ7NnQ L7nYyWyqOZ/r0tM31lQYuOOSiM5XqBWPRlGToGFpIzIsT+huXaYIxNSc7MsAhf7G 5fHis0KrprXG1Rn5BhDUwgOxPyWDcAfg/iYmZhulVUEQar/shqdF22eM1lClzBqe QPoQiyoXA9Q7JW307O7fGJt/8ih/03U+yH1pkvjcoZ0Cltzmu+UZT+irOX8rtocK ABF+B6JPieZFk7QrlOyYKKFEtDyE9BjyKP9Lg5zeY7OMukhK/m9+hu7U+n/MsJPi U5kFRwNX3E2jKAnLP2CFgJakr4OICY0XIGmMV0v6coAQQGHTBhJhQ7IlEKcilCYL W/cPeOadKI1NHlvYHDxp1qp4tJiso7up7Vx5zLx/064lR+vrAv3c33Mn6zzMYvMC R9uqODuYJvdgB/DV084m =DHRq -----END PGP SIGNATURE-----
On Feb 20, 2014, at 2:44 PM, Stefan Dösinger wrote:
Am 2014-02-20 17:20, schrieb Ken Thomases:
Besides running under an emulator, it may be possible to wrap every call out to system libraries with code to save and restore the register. Or, if you prefer to think of it this way, the wrapper would be on exit from and entry back into native Windows binary code. This would be somewhat similar to what we do with stack alignment, although we have compiler help for that. Either way, that would probably impose a significant performance penalty. Sounds much more pleasant than an emulator. But doesn't the problem also affect multitasking context switches?
It's conceivable, but I don't know if it actually happens.
I have some llvm work (__ms_hook_prologue__) on my todo list anyway. Maybe it's an idea to add a compiler feature to take care of this.
This will actually be more complicated than stack alignment (__force_align_arg_pointer__) and the hook prologue. With stack alignment, Windows code is not allergic to 16-byte-aligned stack, it just fails to maintain it. So, it's sufficient for us to force 16-byte alignment when Windows code calls into Wine code. When Wine code calls out to Windows code, there's nothing we need to do. So, putting the attribute in the WINAPI declspec works. With this register issue, there are two approaches: 1) Wrap all calls out to system libraries. Save the register, restore what the OS X ABI expects/requires, call the system API, restore the original value of the register. 2) Conceptually wrap the Windows code. This has a component similar to stack alignment and the hook prologue, but also has to affect all places that call out to Windows code. Where Windows code calls Wine code, we'd save the Windows value of the register and restore the OS X ABI value. When the Wine code returns, it would restore the Windows value. But also, wherever Wine calls out to Windows code, it will have to save the OS X ABI value, restore the Windows value, do the call-out, then restore the OS X ABI value. With either approach, the problem is that there's work that needs to happen at call sites, not just entry points to WINAPI functions. I don't know how to identify such call sites. They're ubiquitous but anonymous. Perhaps the CALLBACK declspec would help for approach 2, but I doubt it will be thorough enough. I suppose the third approach would be to just compile all Wine code such that it does this dance at every call site. Yikes! -Ken
Am 20.02.2014 um 22:51 schrieb Ken Thomases <ken(a)codeweavers.com>:
This will actually be more complicated than stack alignment (__force_align_arg_pointer__) and the hook prologue. With stack alignment, Windows code is not allergic to 16-byte-aligned stack, it just fails to maintain it. So, it's sufficient for us to force 16-byte alignment when Windows code calls into Wine code. When Wine code calls out to Windows code, there's nothing we need to do. So, putting the attribute in the WINAPI declspec works. Good point.
1) Wrap all calls out to system libraries. Save the register, restore what the OS X ABI expects/requires, call the system API, restore the original value of the register. We’d also have to take care of places where the system API calls us. I guess the problem is essentially the same as in option 2. I think 2 is the better approach. With 1 there may be cases where the compiler generates code from the Wine sources that expects the OSX register setup.
2) Conceptually wrap the Windows code. This has a component similar to stack alignment and the hook prologue, but also has to affect all places that call out to Windows code. Where Windows code calls Wine code, we'd save the Windows value of the register and restore the OS X ABI value. When the Wine code returns, it would restore the Windows value. But also, wherever Wine calls out to Windows code, it will have to save the OS X ABI value, restore the Windows value, do the call-out, then restore the OS X ABI value. There are more problems: I doubt that we can store the register values on the stack. It would probably need some thread local storage, which would be a Wine-specific location. (Isn’t the entire issue about the TLS pointer?). Putting this Wine-specific knowledge into the compiler would be very ugly. Even formulating a reasonable interface for such a compiler feature will be a challenge.
A better option than the WINAPI / CDECL attribute might be exported symbols, quite like +relay works. But then we need a solution for COM methods. Also, what happens if Wine code calls a public Windows function? The register store / restore function should be save to apply in this case.
Stefan its surprising how both Windows and OSX run on the same Intel platform but in very different ways. However when you consider the pedigree of these systems it's not so surprising. They come from very different worlds. Thank you gentlemen. It's pretty clear then it's not available now, nor will it be without some significant effort. I understand the conversation thus far if not some of the finer details. You have answered my question. On Fri, Feb 21, 2014 at 10:09 PM, Stefan Dösinger <stefandoesinger(a)gmail.com
wrote:
Am 20.02.2014 um 22:51 schrieb Ken Thomases <ken(a)codeweavers.com>:
This will actually be more complicated than stack alignment (__force_align_arg_pointer__) and the hook prologue. With stack alignment, Windows code is not allergic to 16-byte-aligned stack, it just fails to maintain it. So, it's sufficient for us to force 16-byte alignment when Windows code calls into Wine code. When Wine code calls out to Windows code, there's nothing we need to do. So, putting the attribute in the WINAPI declspec works. Good point.
1) Wrap all calls out to system libraries. Save the register, restore what the OS X ABI expects/requires, call the system API, restore the original value of the register. We'd also have to take care of places where the system API calls us. I guess the problem is essentially the same as in option 2. I think 2 is the better approach. With 1 there may be cases where the compiler generates code from the Wine sources that expects the OSX register setup.
2) Conceptually wrap the Windows code. This has a component similar to stack alignment and the hook prologue, but also has to affect all places that call out to Windows code. Where Windows code calls Wine code, we'd save the Windows value of the register and restore the OS X ABI value. When the Wine code returns, it would restore the Windows value. But also, wherever Wine calls out to Windows code, it will have to save the OS X ABI value, restore the Windows value, do the call-out, then restore the OS X ABI value. There are more problems: I doubt that we can store the register values on the stack. It would probably need some thread local storage, which would be a Wine-specific location. (Isn't the entire issue about the TLS pointer?). Putting this Wine-specific knowledge into the compiler would be very ugly. Even formulating a reasonable interface for such a compiler feature will be a challenge.
A better option than the WINAPI / CDECL attribute might be exported symbols, quite like +relay works. But then we need a solution for COM methods.
Also, what happens if Wine code calls a public Windows function? The register store / restore function should be save to apply in this case.
On Thu, Feb 20, 2014 at 12:44 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-02-20 17:20, schrieb Ken Thomases:
Besides running under an emulator, it may be possible to wrap every call out to system libraries with code to save and restore the register. Or, if you prefer to think of it this way, the wrapper would be on exit from and entry back into native Windows binary code. This would be somewhat similar to what we do with stack alignment, although we have compiler help for that. Either way, that would probably impose a significant performance penalty. Sounds much more pleasant than an emulator. But doesn't the problem also affect multitasking context switches?
I have some llvm work (__ms_hook_prologue__) on my todo list anyway. Maybe it's an idea to add a compiler feature to take care of this.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTBmkoAAoJEN0/YqbEcdMwktIP/11AS7Dv48LWFM+cmwVkWtld H7mHGe5Az6AYk8LeAfqXyA+tgk9MUtir8TQXZV3/6dAzLysf9kKDrikTPrSuqe8x IhJyNPz5asiMDHwzUJLTkXoaefLPZYDIzEu8Ce0VuBOwiprK4CXdv2b43p3E+hyU v5ERW0n01UBnQSKwDBwe60baRp7ToFv1BxNBATpidNZBdBIcKGpuqMVn2/nPytow GSytIVEFTlnE7d+DiQnzANyiOUVbeM8mjkHNJGTaYi9xD/WrPksA7ZZw8RIZ7NnQ L7nYyWyqOZ/r0tM31lQYuOOSiM5XqBWPRlGToGFpIzIsT+huXaYIxNSc7MsAhf7G 5fHis0KrprXG1Rn5BhDUwgOxPyWDcAfg/iYmZhulVUEQar/shqdF22eM1lClzBqe QPoQiyoXA9Q7JW307O7fGJt/8ih/03U+yH1pkvjcoZ0Cltzmu+UZT+irOX8rtocK ABF+B6JPieZFk7QrlOyYKKFEtDyE9BjyKP9Lg5zeY7OMukhK/m9+hu7U+n/MsJPi U5kFRwNX3E2jKAnLP2CFgJakr4OICY0XIGmMV0v6coAQQGHTBhJhQ7IlEKcilCYL W/cPeOadKI1NHlvYHDxp1qp4tJiso7up7Vx5zLx/064lR+vrAv3c33Mn6zzMYvMC R9uqODuYJvdgB/DV084m =DHRq -----END PGP SIGNATURE-----
While you're in there, builtin_ms_va_list ( http://llvm.org/bugs/show_bug.cgi?id=8851) would be nice, to see how clang does with wine64. -- -Austin
well, google is my friend, i uswd the gcc wrapper with wine ../wine-1.7.8/configure --enable-win64 --disable-option-checking --without-oss --without-cms --without-v4l --without-alsa --without-audioio --without-capi --with-coreaudio --without-esd --without-hal --without-jack --with-xcomposite --with-xcursor --with-xinerama --with-xinput --with-xml --with-xrandr --with-xrender --with-xshape --with-xshm --with-xslt --with-xxf86vm --with-x --without-fontconfig --without-gphoto --without-gstreamer --without-dbus --disable-win16 --verbose and in the _ms_vs_list headers: #ifndef __ms_va_list //HACK //# if defined(__x86_64__) && defined (__GNUC__) //# define __ms_va_list __builtin_ms_va_list //# define __ms_va_start(list,arg) __builtin_ms_va_start(list,arg) //# define __ms_va_end(list) __builtin_ms_va_end(list) //# else # define __ms_va_list va_list # define __ms_va_start(list,arg) va_start(list,arg) # define __ms_va_end(list) va_end(list) //# endif #endif (_va.list.h): typedef __darwin_va_list va_list; or somewhere else... and in macho-module.c: static BOOL macho_load_file(struct process* pcs, const WCHAR* filename, ... if (!ret) { static void* dyld_all_image_infos_addr; /* Our next best guess is that dyld was loaded at its base address and we can find the dyld image infos address by looking up its symbol. */ if (!dyld_all_image_infos_addr) { //HACK struct nlist_64 nl[2]; memset(nl, 0, sizeof(nl)); task_dyld_info_data_t dyld_info; mach_msg_type_number_t count = TASK_DYLD_INFO_COUNT; task_info(mach_task_self(), TASK_DYLD_INFO, (task_info_t)&dyld_info, &count); nl[0].n_un.n_strx = (struct dyld_all_image_infos *)dyld_info.all_image_info_addr; // if (!nlist_64("/usr/lib/dyld", nl)) //<---- here comes a linker error if i enable this //------------ dyld_all_image_infos_addr = (void*)nl[0].n_value; now, there is a problem with: signal_x86_64.c. it has not the correct signal handlers for darwin. for example: context->u.FltSave = (XMM_SAVE_AREA32*)*FPU_sig(sigcontext); error. because typedef _STRUCT_FP_CONTROL __darwin_fp_control_t; #else /* !__DARWIN_UNIX03 */ #define _STRUCT_FP_CONTROL struct fp_control _STRUCT_FP_CONTROL { unsigned short invalid :1, denorm :1, zdiv :1, ovrfl :1, undfl :1, precis :1, :2, pc :2, ... }; typedef _STRUCT_FP_CONTROL fp_control_t; in _STRUCT_X86_FLOAT_STATE32 <--- this is the type of the sigcontext in darwin { int __fpu_reserved[2]; _STRUCT_FP_CONTROL __fpu_fcw; /* x87 FPU control word */ <---theese are structs _STRUCT_FP_STATUS __fpu_fsw; /* x87 FPU status word */ <----... __uint8_t __fpu_ftw; /* x87 FPU tag word */ __uint8_t __fpu_rsrv1; /* reserved */ ... and in typedef struct _XMM_SAVE_AREA32 { WORD ControlWord; /* 000 */ <---- WORD values! WORD StatusWord; /* 002 */ <---- BYTE TagWord; /* 004 */ so, i dunno which values are actually being used until deeper look into wine code -- View this message in context: http://wine.1045685.n5.nabble.com/Wine-64-bit-tp5788608p5823429.html Sent from the Wine - Devel mailing list archive at Nabble.com.
Hi, I am attaching a new patch to get Wine building and running 64-bit on OS X. This now launches built-in programs like winecfg, etc. I have also run the MSI installers for SketchUp and 7-Zip; although they seemed to go through to completion, they didn't work completely correctly. (I'm not sure prefix creation was right, either.) This is based on strooka's work at <https://github.com/strook/wine-dev-x86_64/commit/5dd3cca2200cdf1b6fa5afb185e5086500df4130>. (I started this before his subsequent commit and my work largely eliminates the need for that one.) I have rebased onto current git tip (wine-1.7.33-191-ge899bd8). strooka's work was based on 1.7.8. This is still a hack-and-slash job, although I have cleaned up some of strooka's work. In particular, the changes to dlls/ntdll/signal_x86_64.c are much simpler and cleaner. Since it's a hack job, it will break builds for other platforms/architectures, including 32-bit Wine for OS X. As a consequence, you would have to maintain separate source bases to build a shared WoW64 setup. I haven't tried yet. The configure line that strooka recommended had a lot of extraneous stuff. I configured with: ./configure --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib --enable-win64 --disable-wineqtdecoder --disable-win16 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: [HKEY_CURRENT_USER\Software\Wine\Drivers] "Graphics"="x11" Thanks to strooka for his initial work and for charging into the breach like a possessed person and piquing my interest. :-D -Ken
On Jan 8, 2015, at 10:11 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
Hi,
I am attaching a new patch to get Wine building and running 64-bit on OS X. This now launches built-in programs like winecfg, etc. I have also run the MSI installers for SketchUp and 7-Zip; although they seemed to go through to completion, they didn't work completely correctly. (I'm not sure prefix creation was right, either.)
This is based on strooka's work at <https://github.com/strook/wine-dev-x86_64/commit/5dd3cca2200cdf1b6fa5afb185e5086500df4130>. (I started this before his subsequent commit and my work largely eliminates the need for that one.)
I have rebased onto current git tip (wine-1.7.33-191-ge899bd8). strooka's work was based on 1.7.8. Funny you should mention that, since I have my own patches for Wine64 on Mac OS, which I’m now attaching to this email. It’s a bit less hacky than strooka’s (even if I do say so myself), in part because the __ms_va_list stuff isn’t defined away. I have rebased my patches onto Wine HEAD as of tonight.
Apple GCC won’t work for obvious reasons, so you need either vanilla GCC or Clang. I haven’t tested with FSF GCC, but if you use Clang, you need to build it yourself with some patches against LLVM and Clang that I wrote (and that I have also attached), but haven’t yet bothered upstreaming. Some of them fix nasty miscompiles when mixing System V and Win64 calling conventions, and others, of course, add support for __ms_va_list. They are, of course, against LLVM tip-of-tree. Mine doesn’t seem to work correctly, either; there are some other issues that may or may not be related to Clang/LLVM miscompiles that I haven’t fixed yet. In particular, there were some pretty hairy issues with DWARF debug information that made symbolic debugging nigh impossible.
This is still a hack-and-slash job, although I have cleaned up some of strooka's work. In particular, the changes to dlls/ntdll/signal_x86_64.c are much simpler and cleaner.
Since it's a hack job, it will break builds for other platforms/architectures, including 32-bit Wine for OS X. As a consequence, you would have to maintain separate source bases to build a shared WoW64 setup. I haven't tried yet.
My patches do not have this problem ;). I had my eye on WoW64 from the start.
The configure line that strooka recommended had a lot of extraneous stuff. I configured with:
./configure --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib --enable-win64 --disable-wineqtdecoder --disable-win16
I thought --disable-win16 was implicit in --enable-win64. Also, one of my patches automatically disables wineqtdecoder if Wine64 is enabled.
The Mac driver crashes in a 64-bit build for reasons I haven't investigated, so you have to use the X11 driver.
Yipe! I think I recall having this problem myself. Chip
On Jan 9, 2015, at 3:56 AM, cdavis5x(a)gmail.com wrote:
Funny you should mention that, since I have my own patches for Wine64 on Mac OS, which I’m now attaching to this email. It’s a bit less hacky than strooka’s (even if I do say so myself), in part because the __ms_va_list stuff isn’t defined away. I have rebased my patches onto Wine HEAD as of tonight.
Should have replied earlier, but… this is good stuff. A number of these patches should just be submitted now. They would be good to have even if they don't eventually get us to working 64-bit Wine on OS X:
0001-libwine-Add-exports-file-for-Mac-OS.patch
Not sure what this is about. I assume this is about restricting what symbols are exported. Is there a problem with excessive exports?
0002-configure-Don-t-build-a-64-bit-wineqtdecoder.patch
I don't have a problem with this as is, but Alexandre may prefer an actual test of QuickTime's availability.
0003-configure-Support-64-bit-compilation-on-Mac-OS.patch
Regarding the -pagezero_size option: 1) it might as well be unconditional. The 32-bit code assumes a 4096-byte page-zero, implicit in the base address of WINE_DOS. 2) I assume it works to specify it in decimal or you'd still be getting linker errors. However, the ld man page says it is interpreted as hexadecimal with or without a leading "0x". So, probably better to specify it in hex.
0004-winebuild-Make-emitting-mod_-_func-sections-on-Mac-O.patch
This is clearly just better than the current code, which effectively has magic numbers. I hadn't even bothered looking closely enough at this code to learn of the existence of get_ptr_size() and get_asm_ptr_keyword(). Sure makes my hack seem… extra hack-ish. ;)
0005-server-Use-mach_vm_-functions-instead-of-the-old-vm_.patch
Seems good.
0006-ntdll-Support-64-bit-Mac-OS.patch
Is the addition of the __wine_current_teb() your attempt to get around the fact that NtCurrentTeb() is inlined on other 64-bit platforms but has to be exported on OS X? Is it possible to define NtCurrentTeb() such that it's inlined but also exported by ntdll on the other platforms? This solution seems excessively convoluted. I'm not sure we care about 10.5 with the 64-bit support. That avoids the conditional definitions of the context accessor macros. You seem to have some cruft. Is the #include <sys/sysctl.h> used? Certainly there's an empty #ifdef __APPLE__/#endif pair. (I realize you're not done and I'm not one to talk given the hackfest I horked up. Just trying to help. ;)
0007-dbghelp-Support-64-bit-dyld_all_image_infos-structur.patch
There's going to be a lot more that needs to be done for the dbghelp support. It currently uses 32-bit-specific Mach-O structures and constants (e.g. MH_MAGIC, CPU_TYPE_X86, LC_SEGMENT, and struct segment_command). I haven't checked if a 32-bit dbghelp will be expected to analyze a 64-bit process or vice versa.
0008-kernel32-Don-t-use-gs-on-64-bit-Mac-OS.patch 0009-kernel32-Recognize-64-bit-Mach-O-modules-too.patch 0010-kernel32-Also-recognize-and-handle-Mach-O-fat-binari.patch 0011-msvcrt-Support-64-bit-platforms-that-don-t-have-fini.patch
These all look fine. Thanks! I'll be interested to see where this leads. -Ken
On Jan 22, 2015, at 8:58 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jan 9, 2015, at 3:56 AM, cdavis5x(a)gmail.com wrote:
Funny you should mention that, since I have my own patches for Wine64 on Mac OS, which I’m now attaching to this email. It’s a bit less hacky than strooka’s (even if I do say so myself), in part because the __ms_va_list stuff isn’t defined away. I have rebased my patches onto Wine HEAD as of tonight.
Should have replied earlier, but… this is good stuff. A number of these patches should just be submitted now. They would be good to have even if they don't eventually get us to working 64-bit Wine on OS X:
0001-libwine-Add-exports-file-for-Mac-OS.patch
Not sure what this is about. I assume this is about restricting what symbols are exported. Is there a problem with excessive exports? Oh this? A while ago, I noticed that when building everywhere else, libwine restricts its exports (cf. wine.def and wine.map). I guess this is necessary for Windows (because we don’t mark the APIs with __declspec(dllexport)), but we do this on ELF platforms, too. And so I thought to myself, why aren’t we doing this on Mac, too?
This happened to be in my tree when I wrote the other patches. #3 depends on it right now, and I didn’t feel like rewriting it not to need it at the time I packaged up these patches for you guys. If Alexandre won’t take it, I guess I can remove this patch.
0002-configure-Don-t-build-a-64-bit-wineqtdecoder.patch
I don't have a problem with this as is, but Alexandre may prefer an actual test of QuickTime's availability.
I imagine he would, given that a) Apple is likely to remove the QuickTime headers at some point, and b) testing for availability is good autoconf practice anyway. I’ll fix that.
0003-configure-Support-64-bit-compilation-on-Mac-OS.patch
Regarding the -pagezero_size option: 1) it might as well be unconditional. The 32-bit code assumes a 4096-byte page-zero, implicit in the base address of WINE_DOS.
It’s conditional in my tree because I have another patch that turns off the __PAGEZERO segment, then sticks the WINE_DOS segment at address 0. I submitted that patch once, but Alexandre rejected it because we lack V86 support anyway on Mac OS, so what’s it matter if Win16 and Win9x programs can’t access the IVT, BDA or DOS Data Segment? :) I guess I could make it unconditional (since he’s not going to take my patch to make it 0 on 32-bit), but it’d be redundant on 32-bit, because the default size of the __PAGEZERO segment there is 4k.
2) I assume it works to specify it in decimal or you'd still be getting linker errors. However, the ld man page says it is interpreted as hexadecimal with or without a leading "0x". So, probably better to specify it in hex. I must have glossed over that when I was reading the ld(1) man page. I’ll definitely fix that——even if, in the grand scheme of things, it won’t make that much more memory available.
0004-winebuild-Make-emitting-mod_-_func-sections-on-Mac-O.patch
This is clearly just better than the current code, which effectively has magic numbers. I hadn't even bothered looking closely enough at this code to learn of the existence of get_ptr_size() and get_asm_ptr_keyword(). Sure makes my hack seem… extra hack-ish. ;) I'll submit this right away.
0005-server-Use-mach_vm_-functions-instead-of-the-old-vm_.patch
Seems good. This too.
0006-ntdll-Support-64-bit-Mac-OS.patch
Is the addition of the __wine_current_teb() your attempt to get around the fact that NtCurrentTeb() is inlined on other 64-bit platforms but has to be exported on OS X? Yep. I didn’t want to add an export of an NT API that is not exported on Windows. I’m just afraid that some program out there depends specifically on NtCurrentTeb() not being in ntdll’s export table on x64. Yes, I know it sounds paranoid, but you just never know what programs in the wild (at least, the proprietary ones) depend on. Is it possible to define NtCurrentTeb() such that it's inlined but also exported by ntdll on the other platforms? Given that that’s what we already do for some other API functions, probably. (GetLastError() in kernel32 comes to mind.) This solution seems excessively convoluted.
I'm not sure we care about 10.5 with the 64-bit support. That avoids the conditional definitions of the context accessor macros. Should we then refuse to build Wine at all on Darwin 9 (= OS X 10.5)? There’s some more conditional checks we can then get rid of if we require Mac OS 10.6.
You seem to have some cruft. Is the #include <sys/sysctl.h> used? Nope, and I meant to get rid of that. It was used in an earlier version of my patch to set kern.thaltstack, but when I removed that (because it’s a no-op in Mac OS >= 10.5), I forgot to remove the #include. Certainly there's an empty #ifdef __APPLE__/#endif pair. (I realize you're not done and I'm not one to talk given the hackfest I horked up. Just trying to help. ;) Hey, it’s no problem. I appreciate help.
0007-dbghelp-Support-64-bit-dyld_all_image_infos-structur.patch
There's going to be a lot more that needs to be done for the dbghelp support. I know. But the nlist(3) call isn’t available on 64-bit, nor is the n_un.n_name field in struct nlist{,_64}——even when inspecting a 32-bit binary. (I wonder if Alexandre would prefer configure checks for those…) So it wouldn’t build at all as is, and while I was in there I figured I’d fix it more or less the right way. It currently uses 32-bit-specific Mach-O structures and constants (e.g. MH_MAGIC, CPU_TYPE_X86, LC_SEGMENT, and struct segment_command). I haven't checked if a 32-bit dbghelp will be expected to analyze a 64-bit process or vice versa. I should check on that. I never did actually try to use a 64-bit WinDbg/CDB/NTSD on a 32-bit binary, so I’m curious to know if that would work.
0008-kernel32-Don-t-use-gs-on-64-bit-Mac-OS.patch 0009-kernel32-Recognize-64-bit-Mach-O-modules-too.patch 0010-kernel32-Also-recognize-and-handle-Mach-O-fat-binari.patch 0011-msvcrt-Support-64-bit-platforms-that-don-t-have-fini.patch
These all look fine. I’ll submit all of these.
Thanks! I'll be interested to see where this leads. Thanks for the review!
Chip
-Ken
On Jan 23, 2015, at 12:03 AM, cdavis5x(a)gmail.com wrote:
On Jan 22, 2015, at 8:58 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
0006-ntdll-Support-64-bit-Mac-OS.patch
Is the addition of the __wine_current_teb() your attempt to get around the fact that NtCurrentTeb() is inlined on other 64-bit platforms but has to be exported on OS X?
Yep. I didn’t want to add an export of an NT API that is not exported on Windows. I’m just afraid that some program out there depends specifically on NtCurrentTeb() not being in ntdll’s export table on x64. Yes, I know it sounds paranoid, but you just never know what programs in the wild (at least, the proprietary ones) depend on.
Yeah, I realized after I sent that that NtCurrentTeb() must not be exported on Windows for 64-bit. So, your approach is probably right. It shouldn't be exported in Wine, either.
I'm not sure we care about 10.5 with the 64-bit support. That avoids the conditional definitions of the context accessor macros. Should we then refuse to build Wine at all on Darwin 9 (= OS X 10.5)? There’s some more conditional checks we can then get rid of if we require Mac OS 10.6.
I don't know if Alexandre will allow that. He wasn't willing to drop support for 10.5 back when the Mac driver was added. He was even kind of grumpy that the Mac driver itself required 10.6. At the time, he had an old Mac Mini that couldn't be upgraded past 10.5 that he continued to build and test on. Perhaps if dropping 10.5 gained us something, he could be persuaded. I just figured that support for an additional architecture could be restricted, since it doesn't remove something that used to work. On the other hand, if the only concession we need to make is this set of macros being defined two different ways, that's not much of a cost.
0007-dbghelp-Support-64-bit-dyld_all_image_infos-structur.patch
There's going to be a lot more that needs to be done for the dbghelp support. I know.
Yeah, I didn't really mean to say that was a problem with this patch. Just musing about what ultimately needs to be done.
But the nlist(3) call isn’t available on 64-bit, nor is the n_un.n_name field in struct nlist{,_64}
Huh. I realized the n_name field was missing, but didn't realize that nlist() isn't available. The function declaration isn't excluded for __LP64__ in the header, but, you're right, it's not exported by libSystem or its sub-libraries.
——even when inspecting a 32-bit binary. (I wonder if Alexandre would prefer configure checks for those…) So it wouldn’t build at all as is, and while I was in there I figured I’d fix it more or less the right way.
Thanks for the review!
You're welcome. :) -Ken
Ken, On 01/23/2015 07:32 AM, Ken Thomases wrote:
I don't know if Alexandre will allow that. He wasn't willing to drop support for 10.5 back when the Mac driver was added. He was even kind of grumpy that the Mac driver itself required 10.6. At the time, he had an old Mac Mini that couldn't be upgraded past 10.5 that he continued to build and test on.
Perhaps if dropping 10.5 gained us something, he could be persuaded. persuading Alexandre with that is difficult, nay impossible.
But you do not have to do that, the solution is much simpler: Just prove that nobody is using Wine on MacOSX 10.5. And if the only user turns out to be Alexandre himself then pester Jeremey to buy Alexandre a new Mac Mini. bye michael
I was interested in compiling 64-bit wine on OS X the other day and hit some problems, so I thought I would resurrect this thread. I used gcc 4.8 from macports, because as far as I could tell there wasn't a chance of using any version of clang without patching it. Using gcc I hit winehq bug 38380 right away: https://bugs.winehq.org/show_bug.cgi?id=38380 With Ken's help I tried the attached patch, which allowed a few places where wine has assembly code calling 64-bit windows functions to assemble with Apple's broken assembler. The only other problem I hit was the pagezero thing discussed below: On 1/23/15 12:03 AM, cdavis5x(a)gmail.com wrote:
0003-configure-Support-64-bit-compilation-on-Mac-OS.patch Regarding the -pagezero_size option: 1) it might as well be unconditional. The 32-bit code assumes a 4096-byte page-zero, implicit in the base address of WINE_DOS. It’s conditional in my tree because I have another patch that turns off the __PAGEZERO segment, then sticks the WINE_DOS segment at address 0. I submitted that patch once, but Alexandre rejected it because we lack V86 support anyway on Mac OS, so what’s it matter if Win16 and Win9x programs can’t access the IVT, BDA or DOS Data Segment? :) I guess I could make it unconditional (since he’s not going to take my patch to make it 0 on 32-bit), but it’d be redundant on 32-bit, because the default size of the __PAGEZERO segment there is 4k. Did any resolution to this problem ever appear? If that were fixed and we had a workaround for the broken Apple assembler, I think you could compile and test 64-bit wine on OS X. (The mac driver still won't compile without clang, but passing --disable-winemac.drv at least allowed use of the X11 driver.)
I haven't tested much so far, but I at least got a working prefix and ran notepad (once with relay logging, even).
Sorry for the belated response. GCC takes forever to build on my system.
On Apr 28, 2015, at 8:26 AM, Josh DuBois <duboisj(a)codeweavers.com> wrote:
I was interested in compiling 64-bit wine on OS X the other day and hit some problems, so I thought I would resurrect this thread. I used gcc 4.8 from macports, because as far as I could tell there wasn't a chance of using any version of clang without patching it. Using gcc I hit winehq bug 38380 right away:
https://bugs.winehq.org/show_bug.cgi?id=38380
With Ken's help I tried the attached patch, which allowed a few places where wine has assembly code calling 64-bit windows functions to assemble with Apple's broken assembler. I don’t use Apple’s broken as(1), because I patch Clang, whose integrated assembler is decidedly un-broken. That’s why I never submitted a patch for that. (In fact, it’s possible to make as(1) invoke Clang to do the assembly, if you pass it the ‘-q’ switch.)
I still need to get my __ms_va_list patches upstream into LLVM/Clang, but there’s a big rewrite going on related to pointer types in LLVM IR that affects my patch (i.e. it’ll make it simpler), so I’m waiting for that to go through first.
The only other problem I hit was the pagezero thing discussed below:
On 1/23/15 12:03 AM, cdavis5x(a)gmail.com wrote:
0003-configure-Support-64-bit-compilation-on-Mac-OS.patch Regarding the -pagezero_size option: 1) it might as well be unconditional. The 32-bit code assumes a 4096-byte page-zero, implicit in the base address of WINE_DOS. It’s conditional in my tree because I have another patch that turns off the __PAGEZERO segment, then sticks the WINE_DOS segment at address 0. I submitted that patch once, but Alexandre rejected it because we lack V86 support anyway on Mac OS, so what’s it matter if Win16 and Win9x programs can’t access the IVT, BDA or DOS Data Segment? :) I guess I could make it unconditional (since he’s not going to take my patch to make it 0 on 32-bit), but it’d be redundant on 32-bit, because the default size of the __PAGEZERO segment there is 4k. Did any resolution to this problem ever appear?
Just now, attached to this email. ;) (NOTE: You’ll have to regenerate configure after applying this change.)
If that were fixed and we had a workaround for the broken Apple assembler, I think you could compile and test 64-bit wine on OS X. (The mac driver still won't compile without clang, but passing --disable-winemac.drv at least allowed use of the X11 driver.)
I haven't tested much so far, but I at least got a working prefix and ran notepad (once with relay logging, even). That’s great! In fact, that’s actually further than I get building with Clang—even with my patches applied to it. (It doesn’t help that Clang produces broken DWARF unwind info for Win64 ABI functions, which I really need to fix…)
By the way, I can tell you right now that WoW64 won’t work quite yet. Mac OS has no separate lib32/lib64 directories, so we need to produce fat DLLs. I have another patch (also attached) to teach kernel32 to recognize fat binaries, but there’s no build system infrastructure for making fat DLLs yet. If you want to try out WoW64, you’ll have to do that manually with lipo(1). (I’ve actually submitted this second patch, but AJ hasn’t taken it. I guess he’s unconvinced that it’s correct. Maybe if we try out WoW64 and it works, he’ll be more convinced. ;) Chip
Charles Davis <cdavis5x(a)gmail.com> writes:
By the way, I can tell you right now that WoW64 won’t work quite yet. Mac OS has no separate lib32/lib64 directories, so we need to produce fat DLLs. I have another patch (also attached) to teach kernel32 to recognize fat binaries, but there’s no build system infrastructure for making fat DLLs yet. If you want to try out WoW64, you’ll have to do that manually with lipo(1). (I’ve actually submitted this second patch, but AJ hasn’t taken it. I guess he’s unconvinced that it’s correct. Maybe if we try out WoW64 and it works, he’ll be more convinced. ;)
You'd have to make a more convincing argument for this. Not having lib32/lib64 is not an issue since Wine is looking for dlls in its own directory anyway. It would be trivial to use lib/wine32 and lib/wine64 or some similar scheme. -- Alexandre Julliard julliard(a)winehq.org
On 4/29/15 12:40 AM, Charles Davis wrote:
I don’t use Apple’s broken as(1), because I patch Clang, whose integrated assembler is decidedly un-broken. That’s why I never submitted a patch for that. (In fact, it’s possible to make as(1) invoke Clang to do the assembly, if you pass it the ‘-q’ switch.) Ah. Passing -q to as gave me a raft of errors the first time I tried. Clang's assembler choked on unrecognized .stabs directives and would not assemble, but removing -gstabs+ from the compile line allows clang to assemble relay.s without changing the movq instructions by passing -q to as. I'm not familiar with the impact, if any, that will have on debugging.
It still seems useful to me to be able to assemble with Apples as and compile with gcc. Is there harm in changing the various movq instructions to be compatible with Apple's as?
That’s great! In fact, that’s actually further than I get building with Clang—even with my patches applied to it. (It doesn’t help that Clang produces broken DWARF unwind info for Win64 ABI functions, which I really need to fix…)
By the way, I can tell you right now that WoW64 won’t work quite yet. Someone on bug 38380 claims to have gotten even father and successfully run 64-bit windows code. All of the 64-bit windows apps I tried seemed to have 32-bit installers, so I guess WoW64 is really necessary to give it a good try.
On Apr 29, 2015, at 7:25 AM, Josh DuBois <duboisj(a)codeweavers.com> wrote:
On 4/29/15 12:40 AM, Charles Davis wrote:
I don’t use Apple’s broken as(1), because I patch Clang, whose integrated assembler is decidedly un-broken. That’s why I never submitted a patch for that. (In fact, it’s possible to make as(1) invoke Clang to do the assembly, if you pass it the ‘-q’ switch.) Ah. Passing -q to as gave me a raft of errors the first time I tried. Clang's assembler choked on unrecognized .stabs directives and would not assemble, but removing -gstabs+ from the compile line allows clang to assemble relay.s without changing the movq instructions by passing -q to as. I'm not familiar with the impact, if any, that will have on debugging. The problem is that dbghelp doesn’t yet know how to find dSYM companions, or that it can read the DWARF data from the object files. (That’s why we don’t use DWARF yet on Mac OS.) The latter is somewhat harder, because any addresses in the DWARF data need to be fixed up to match up with their final locations. For this reason, the linker leaves a small amount of stabs data in the final binary. (Ironic, isn’t it?)
It still seems useful to me to be able to assemble with Apples as and compile with gcc. Is there harm in changing the various movq instructions to be compatible with Apple's as? I’m tempted to say that your fix will reduce the performance of the relays slightly (since we’re loading the XMM registers from memory instead of from registers), but then it occurred to me that since we loaded that chunk of memory recently anyway, it should be cached.
My other concern is that as(1) is basically in maintenance mode now that we have Clang. (That’s why we still have bugs in it like the issue with ‘movq’ from registers.) I think Apple at some point wants to kill it off—or at least make -q the default.
That’s great! In fact, that’s actually further than I get building with Clang—even with my patches applied to it. (It doesn’t help that Clang produces broken DWARF unwind info for Win64 ABI functions, which I really need to fix…)
By the way, I can tell you right now that WoW64 won’t work quite yet. Someone on bug 38380 claims to have gotten even father and successfully run 64-bit windows code. All of the 64-bit windows apps I tried seemed to have 32-bit installers, so I guess WoW64 is really necessary to give it a good try. All right. But even with AJ’s suggestion (using separate wine32/wine64 directories for our DLLs), libwine itself still needs to be built fat, because it’s installed directly to $(libdir). For now, I think I’ll submit my patch to configure.
Chip
On 4/29/15 1:08 PM, Charles Davis wrote:
I’m tempted to say that your fix will reduce the performance of the relays slightly (since we’re loading the XMM registers from memory instead of from registers), but then it occurred to me that since we loaded that chunk of memory recently anyway, it should be cached.
My other concern is that as(1) is basically in maintenance mode now that we have Clang. (That’s why we still have bugs in it like the issue with ‘movq’ from registers.) I think Apple at some point wants to kill it off—or at least make -q the default. I imagine that the performance hit will not be a major problem. If it is important to preserve the current relay code in situations where the change is not necessary for compilation, I suppose it could be made conditional on gcc, or even on the version of as being used. I agree that Apple's old as is probably on its last legs, but it's still in use and at present it still seems to be the easiest route to building 64-bit wine on OS X. (Otherwise you need to use both GCC (for compilation) and Clang (for assembly), and also to modify the build to both use Clang as an assembler and make sure -gstabs+ is not present so that Clang's assembler won't choke on the unrecognized directives.) All right. But even with AJ’s suggestion (using separate wine32/wine64 directories for our DLLs), libwine itself still needs to be built fat, because it’s installed directly to $(libdir). For now, I think I’ll submit my patch to configure. I was able to follow the WoW64 instructions on the winehq wiki and build a 32/64 wine install by just a sudo make install on OS X. Wine's 32-bit stuff went in /usr/local/lib and the 64-bit stuff in /usr/local/lib64 (that latter dir had nothing but wine libs). In your prior post you attached a configure patch that checked for __builtin_ms_va_list support as well as adding -pagezero_size,0x1000 to LDEXECFLAGS. I've still only been using the last hunk of that patch - the pagezero stuff. I didn't see the configure patch come across wine-patches. If you're concerned the rest might not be accepted, maybe a patch with the pagezero stuff alone would make it now?
The prefix I created ran at least one 64-bit Windows application without apparent errors: I ran a 64-bit version of PilotEdit ( http://www.pilotedit.com/Download.html ). The other things I tried crashed, but at least the installation allowed for some testing. Since I've gotten an OS X wine install that runs a 64-bit windows app without using a patched set of build tools, I guess I'll submit the movq patch and see whether that gets in. Maybe then it will be easier to tell how many 64-bit apps will actually run on OS X.
Hi Chip, I saw your patch for 64-bit debug registers. Thanks! It made me wonder if you've got anything else in-progress related to 64-bit on OS X? In particular, are you still working on support for __builtin_ms_va_list in Clang or the problems you mentioned previously about code generation when switching calling conventions? I noticed that a bug with DWARF unwind info got fixed in the Clang/LLVM trunk sometime after 3.6. Was that your doing? (You mentioned something like this in your April 29th email.) If so, thanks! I was thinking of tackling the dbghelp support for 64-bit Mach-O images (although not DWARF debugging info) sometime soon, but maybe you're already working on that. Are you? If so, I'll leave it to you. Cheers, Ken
On Jun 5, 2015, at 12:04 AM, Ken Thomases <ken(a)codeweavers.com> wrote:
Hi Chip,
I saw your patch for 64-bit debug registers. Thanks!
It made me wonder if you've got anything else in-progress related to 64-bit on OS X? In particular, are you still working on support for __builtin_ms_va_list in Clang Yeah, but I’ve had to rethink that patch because they’re doing something to the way the compiler represents pointers internally. Hopefully I’ll have it in by the time 3.7 is released in about a month or so. or the problems you mentioned previously about code generation when switching calling conventions? I just recently fixed a really nasty bug with sibling-call optimization that basically just caused Wine to jump to NULL instead of the program’s entry point when it started up. (Specifically, it stuffed the target address into a callee-save register, then tried to use it *after restoring it from the stack*.) There might be other codegen bugs still lurking, though—my informal testing shows such odd problems as text being a little bigger than it should be and random problems accessing the registry, and I haven’t figured out why yet. (Maybe the first is caused by the second?)
I noticed that a bug with DWARF unwind info got fixed in the Clang/LLVM trunk sometime after 3.6. Was that your doing? Nope. I haven’t had much time to work on this until recently. (You mentioned something like this in your April 29th email.) I thought it might have been broken (and it may very well have been; I recall tracing Wine’s unwinder through the debugger early on and finding that what it was doing didn’t make sense, but it doesn’t seem as broken now, though I still got a stack overflow on the first guard page of the stack in one case), but now the thought has crossed my mind (especially since you sent those patches to use libunwind; it must have occurred to you, too!) that some functions just don’t have traditional DWARF CFI because the linker (and in many cases, Clang directly) emits compact unwind data. Naturally, this doesn’t matter to Apple’s unwinder, because it understands compact unwind and knows it should fall back to CFI if the function it’s trying to unwind doesn’t have it. I thought they emitted (or used to emit) compact unwind side-by-side with CFI, but they might have stopped doing that lately (or they only do it if the compiler puts out CFI, and the linker can produce matching compact unwind data out of it). I was thinking of tackling the dbghelp support for 64-bit Mach-O images (although not DWARF debugging info) sometime soon, but maybe you're already working on that. Are you? Nope. Feel free to go ahead with that. I might still have some more codegen bugs to mercilessly hunt down by groveling over arcane runes.
Chip
Hey, On 09-01-15 06:11, Ken Thomases wrote:
Hi,
I am attaching a new patch to get Wine building and running 64-bit on OS X. This now launches built-in programs like winecfg, etc. I have also run the MSI installers for SketchUp and 7-Zip; although they seemed to go through to completion, they didn't work completely correctly. (I'm not sure prefix creation was right, either.)
This is based on strooka's work at <https://github.com/strook/wine-dev-x86_64/commit/5dd3cca2200cdf1b6fa5afb185e5086500df4130>. (I started this before his subsequent commit and my work largely eliminates the need for that one.)
I have rebased onto current git tip (wine-1.7.33-191-ge899bd8). strooka's work was based on 1.7.8.
This is still a hack-and-slash job, although I have cleaned up some of strooka's work. In particular, the changes to dlls/ntdll/signal_x86_64.c are much simpler and cleaner.
Since it's a hack job, it will break builds for other platforms/architectures, including 32-bit Wine for OS X. As a consequence, you would have to maintain separate source bases to build a shared WoW64 setup. I haven't tried yet.
The configure line that strooka recommended had a lot of extraneous stuff. I configured with:
./configure --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib --enable-win64 --disable-wineqtdecoder --disable-win16
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? Could that be related to the crash?
This was the whole reason why I never tried on osx 64. ~Maarten
On Jan 9, 2015, at 6:01 AM, Maarten Lankhorst <maarten(a)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. There is an incompatibility between the Win64 and OS X ABIs. Win64 apps are free to use %gs for their own purposes while OS X does not guarantee to leave it alone. We're hoping that few actually do use %gs and, so, that they won't break. We can't fix the problem 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. -Ken
Ken Thomases <ken(a)codeweavers.com> writes:
On Jan 9, 2015, at 6:01 AM, Maarten Lankhorst <maarten(a)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.
There is an incompatibility between the Win64 and OS X ABIs. Win64 apps are free to use %gs for their own purposes while OS X does not guarantee to leave it alone. We're hoping that few actually do use %gs and, so, that they won't break. We can't fix the problem 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.
Actually, apps can't use it freely, it's always pointing to the TEB. Any app that attempts direct TEB access will fail more or less mysteriously, depending on what's at the same address in the OS X thread data. Since 64-bit apps don't need the TEB exception chain, direct TEB access should be less frequent than on 32-bit. Things like thread local storage would presumably still use it though. -- Alexandre Julliard julliard(a)winehq.org
On Jan 9, 2015, at 12:18 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jan 9, 2015, at 6:01 AM, Maarten Lankhorst <maarten(a)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
well i made just a quick search for "apple" and "pthread" well pthread is actually open source. :D Von meinem iPad gesendet
Am 09.01.2015 um 20:49 schrieb cdavis5x(a)gmail.com:
On Jan 9, 2015, at 12:18 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jan 9, 2015, at 6:01 AM, Maarten Lankhorst <maarten(a)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
it is here: http://www.opensource.apple.com/source/Libc/Libc-391/pthreads/ look into pthread_internals.h there is a function 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. Von meinem iPad gesendet
Am 09.01.2015 um 20:49 schrieb cdavis5x(a)gmail.com:
On Jan 9, 2015, at 12:18 PM, Ken Thomases <ken(a)codeweavers.com> wrote:
On Jan 9, 2015, at 6:01 AM, Maarten Lankhorst <maarten(a)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
On Jan 9, 2015, at 7:47 PM, Marcel Busse <strooka_ace(a)yahoo.de> wrote:
it is here:
http://www.opensource.apple.com/source/Libc/Libc-391/pthreads/
look into pthread_internals.h
This version of Libc hasn't been current since OS X 10.4 (Tiger). With recent versions of OS X, the pthreads implementation is no longer in Libc and the new code has not been released. In any case, there's also stuff in the kernel to support the userland implementation, and that's no longer open-source, either. Regards, Ken
participants (13)
-
Alexandre Julliard -
Andrew Eikum -
Austin English -
cdavis5x＠gmail.com -
Charles Davis
-
Josh DuBois -
Ken Thomases -
Kevin Davies -
Maarten Lankhorst -
Marcel Busse -
Michael Stefaniuc -
Stefan Dösinger -
strooka