Partially correct. LLVM’s bitcode is a relatively stable format. What isn’t stable is LLVM IR semantics. This is why PNaCl’s bitcode format exists: it’s to lock down the IR semantics just as much as it’s to lock down into a versioned (LLVM’s current format isn’t versioned) binary format.
EDIT: I should note that PNaCl’s bitcode format is a substantially smaller representation vs regular bitcode.
That said, Rust’s bitcode is the same as Clang’s.
Also, apropos to point #2: part of PNaCl’s addition to the LLVM landscape is a set of passes that take any valid LLVM IR (for the most part, there are some unimplemented corner cases) and reduce it into the PNaCl subset.
Somewhat. Most of the work required to make this work was done in LLVM. I’m in the process of upstreaming the changes to PNaCl specific pieces to
pnacl-llvm, so that
pnacl-llvm maybe used verbatim. Most of the work in Rust proper regarded PNaCl’s build process. Other work was put into the process of adding a platform to the standard crates.
My hope is to increase upstream (LLVM master) pressure to accept the PNaCl/NaCl changes. I’ve spoken with a Native Client team member (specifically, JF Bastien) regarding these issues and he assures me of their desire for inclusion. As of the last time they’ve tried to submit the patches, it was decided that there wasn’t enough of a need to include them.
W.r.t. point #2, until the NaCl SDK le32-nacl-ld.gold linker is linked against libc++ instead of libstdc++, this can’t happen (there are symbol conflicts between LLVM’s gold plugin’s (freshly compiled) libstdc++ and the libstdc++ linked against le32-nacl-ld.gold in the tool chain).
Frankly, outside of needing it for DOM access, screw JS. I’ve expressed interest in DOM access (which would be need for a Dart -> PNaCl compiler) from inside PNaCl modules to JF, but that’s quite a tall order to say the least.
Anyway rust-ppapi allows you to create PP_Vars and to subsequently send them to the JS side. Perhaps I should write docs for such?