Closed Bug 840283 Opened 8 years ago Closed 8 years ago

OdinMonkey: Windows support

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: luke, Assigned: luke)

References

Details

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.
Blocks: 840282
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.
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...
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.
(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*.
Browser builds and runs BananaBread.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
> 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.
You need to log in before you can comment on or make changes to this bug.