Wine 64 bit

[Charles Davis]

> On Jun 5, 2015, at 12:04 AM, Ken Thomases <ken at 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