[GHC] #8206: Add support for Portable Native Client

[GHC]

#8206: Add support for Portable Native Client
-------------------------------------------------+-------------------------
       Reporter:  guest                          |             Owner:  Alex
           Type:  feature request                |  Sayers
       Priority:  normal                         |            Status:  new
      Component:  Compiler                       |         Milestone:
       Keywords:  NaCl PNaCl Portable Native     |           Version:
  Client pexe                                    |  Operating System:
   Architecture:  Unknown/Multiple               |  Unknown/Multiple
     Difficulty:  Project (more than a week)     |   Type of failure:
     Blocked By:                                 |  None/Unknown
Related Tickets:                                 |         Test Case:
                                                 |          Blocking:
-------------------------------------------------+-------------------------
 == Motivation ==

 [http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-
 native-client 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 [https://developers.google.com
 /native-client/pepperc/ 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 [http://www.chromium.org/nativeclient/pnacl/bitcode-
 abi##callingconventions 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.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8206>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler