Wine 64 bit

[Charles Davis]

> On Apr 29, 2015, at 7:25 AM, Josh DuBois <duboisj at 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