Add support for Portable Native Client
Motivation
Portable Native Client (PNaCl) is a feature in Google Chrome which (roughly) allows it to use LLVM bitcode like browsers use javascript today. The bitcode is downloaded, validated, compiled, and (safely) executed, with access to an API for manipulating the DOM of the page which loaded it. The dream: Haskell executed in the browser at near-native speed. Unfortunately, while GHC has an LLVM backend, the bitcode it generates doesn't satisfy the PNaCl validator.
Portable Native Client
The user visits a page with an <embed> tag pointing to a "pexe" - a PNaCl bitcode file. The bitcode is downloaded and streamed first into a code validator, and then into a compiler. The resulting machine code is then executed as a memory-protected process. The Pepper API, a library Google provides, provides access to the browser for things like connecting to websockets, playing audio, and communicating with javascript running on the page.
PNaCl is present in Chrome 29 (go to chrome://flags to enable it), and will be enabled for arbitrary sources (the "open web") in Chrome 30. Mozilla have announced that they don't intend to support Native Client.
The Easily-Fixed
The pexe bitcode format is a frozen subset of LLVM bitcode. The PNaCl toolchain provides pnacl-finalize, which translates LLVM bitcode into pexe bitcode.
PNaCl only allows the standard "ccc" calling convention, whereas GHC likes to use its own "cc 10" calling convention. You can make GHC use ccc by using an unregisterised build, for a slow-down factor of about 2.
It seems likely that code-next-to-tables will upset the validator. If so, this can be turned off for a small performance hit.
The Not-So-Easily-Fixed
The validator requires that requests for IO are sent to Pepper. PNaCl also requires that you use newlib instead of glibc. Spawning new processes is forbidden (although creating pthreads is fine). It also seems likely that the validator with take umbrage at calls to mmap, which the GHC runtime uses to request memory allocation.
It seems, therefore, that significant chunks of the RTS will have to be ported.
Trac metadata
| Trac field | Value |
|---|---|
| Version | |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | alex.sayers@gmail.com |
| Operating system | |
| Architecture |