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

List:       wine-devel
Subject:    Re: Wine 64 bit
From:       Charles Davis <cdavis5x () gmail ! com>
Date:       2015-04-29 18:08:54
Message-ID: 15CAC53D-2A66-44A4-9AF1-B6FFF4FDB2EF () gmail ! com
[Download RAW message or body]


> On Apr 29, 2015, at 7:25 AM, Josh DuBois <duboisj@codeweavers.com> wrote:
> =

> On 4/29/15 12:40 AM, Charles Davis wrote:
>> I don=92t use Apple=92s broken as(1), because I patch Clang, whose integ=
rated assembler is decidedly un-broken. That=92s why I never submitted a pa=
tch for that. (In fact, it=92s possible to make as(1) invoke Clang to do th=
e assembly, if you pass it the =91-q=92 switch.)
> Ah.  Passing -q to as gave me a raft of errors the first time I tried.  C=
lang's assembler choked on unrecognized .stabs directives and would not ass=
emble, 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 n=
ot familiar with the impact, if any, that will have on debugging.
The problem is that dbghelp doesn=92t yet know how to find dSYM companions,=
 or that it can read the DWARF data from the object files. (That=92s why we=
 don=92t use DWARF yet on Mac OS.) The latter is somewhat harder, because a=
ny addresses in the DWARF data need to be fixed up to match up with their f=
inal locations. For this reason, the linker leaves a small amount of stabs =
data in the final binary. (Ironic, isn=92t it?)
> =

> It still seems useful to me to be able to assemble with Apples as and com=
pile with gcc.  Is there harm in changing the various movq instructions to =
be compatible with Apple's as?
I=92m tempted to say that your fix will reduce the performance of the relay=
s slightly (since we=92re 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=92s why we still have bugs in it like the issue with =91=
movq=92 from registers.) I think Apple at some point wants to kill it off=
=97or at least make -q the default.
>> That=92s great! In fact, that=92s actually further than I get building w=
ith Clang=97even with my patches applied to it. (It doesn=92t help that Cla=
ng produces broken DWARF unwind info for Win64 ABI functions, which I reall=
y need to fix=85)
>> =

>> By the way, I can tell you right now that WoW64 won=92t work quite yet.
> Someone on bug 38380 claims to have gotten even father and successfully r=
un 64-bit windows code.  All of the 64-bit windows apps I tried seemed to h=
ave 32-bit installers, so I guess WoW64 is really necessary to give it a go=
od try.
All right. But even with AJ=92s suggestion (using separate wine32/wine64 di=
rectories for our DLLs), libwine itself still needs to be built fat, becaus=
e it=92s installed directly to $(libdir). For now, I think I=92ll submit my=
 patch to configure.

Chip



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