OdinMonkey: Windows support

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: luke, Assigned: luke)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

4 years ago
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.
(Assignee)

Updated

4 years ago
Blocks: 840282
(Assignee)

Comment 1

4 years ago
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.
(Assignee)

Comment 2

4 years ago
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.
(Assignee)

Comment 4

4 years ago
(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*.
(Assignee)

Comment 5

4 years ago
Browser builds and runs BananaBread.
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 6

4 years ago
> 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.