840283 - OdinMonkey: Windows support

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Luke Wagner [:luke]]

Other than having a different ABI (which should be abstracted by the ABIArgIter), the main challenge I think is the absence of Unix-style signal handlers.  Instead, we'll need to use SEH which seems to provide all the basic functionality we need.

Comment 1

[Luke Wagner [:luke]]

This cset adds Win64:
  http://hg.mozilla.org/users/lwagner_mozilla.com/odinmonkey/rev/c1150064a2d0
Fortunately, the signal-handling on Windows ended up being pretty similar to Unix once I learned that jits destroy SEH and that AddVectoeredExceptionHandler is the way to go (bug 844196).

Half-way done.  I'll get x86 working on the Unixen first and then the only trouble for Windows should be the hackery to add an LDT entry.

Comment 2

[Luke Wagner [:luke]]

Ultimately I had to abandon segmentation because Win64 (which has a major and growing percentage of Windows users) took away the ability to add an LDT entry.  It seems NaCL ran into the same problem and their solution was to just make the NaCL process 64-bit:
  http://code.google.com/p/nativeclient/wiki/ChromiumIntegration
We can't do that, so I ended up just adding dynamic guards.  This produced a 10-14% slowdown on bullet/zlib, but I'm hoping to get that a little less by folding the alignment mask into the overflow test.  Eventually, we should release a 64-bit Firefox on Windows...

Shell tests passing, waiting for browser to build...

Comment 3

[Sean Stangl [:sstangl]]

Just for informational purposes, my brother pointed out the following about Win64's use of the LDT (from http://www.reactos.org/pipermail/ros-dev/2006-August/008775.html):

"Win64 x86-64 does not implement the LDT.  It does "xor eax, eax \ lldt eax" during startup and that's the end of it.  NtSetLdtEntries is a stub, the trap frame doesn't have an LDT field, and the context-switching code does not have code to switch LDT values."

So it's not just the kernel being obstinate toward userland.

Comment 4

[Luke Wagner [:luke]]

(In reply to Sean Stangl [:sstangl] from comment #3)
> So it's not just the kernel being obstinate toward userland.

Rather, it's the kernel *developers*.

Comment 5

[Luke Wagner [:luke]]

Browser builds and runs BananaBread.

Comment 6

[Mark Seaborn]

> Ultimately I had to abandon segmentation because Win64 (which has a
> major and growing percentage of Windows users) took away the ability
> to add an LDT entry.  It seems NaCL ran into the same problem and
> their solution was to just make the NaCL process 64-bit:
>   http://code.google.com/p/nativeclient/wiki/ChromiumIntegration

Right, that's why the x86-64 NaCl sandbox was invented, because NaCl's original segmentation-based x86-32 sandbox doesn't work on 64-bit Windows.