PNaCl support for Rust

[nicoxx]

Hello,

I want to execute intensive computations on client side in chrome with PNaCl (and avoid C++)…Since Rust use llvm as a backend (which is the PNaCl input), it seems an interesting option.

But Rust currently uses a fork of llvm, and the only example of rust code for PNaCl I found is this hello world (https://github.com/DiamondLovesYou/rust-pnacl-hello-world) from @DiamondLovesYou and it uses a fork of Rust.

This is a great initiative (I’m trying to make it work), but I wonder if there is any plan to support PNaCl on a smoother/more reliable way (ie: with the standard Rust tool-chain)

Thanks for your help,

PS: I posted this on stack-overflow but it has been suggested that here would be a better place.

[DiamondLovesYou]

Rust+PNaCl author here.

There are additional docs for rust-ppapi, located here.

As for pnacl-hello-world, unfortunately there are other problems. For instance, rustc doesn’t produce pexe’s in PNaCl’s stable bitcode format by default (so one can use the bitcode it produces to make a nexe with debugging information, using rust-pnacl-trans), and cargo doesn’t yet (I’m working on this) support post build scripts or arbitrary rustc flags.

Other than the above, what problems are you having?

[nicoxx]

Thanks,

So, from what I understand (please correct me if i’m wrong) :

There is several LLVM codes :

• The “standard” one used by clang
• The one used by PNaCl which is in some sens is a subset of it, that’s why google gives a custom build-chain for C++, because the LLVM code produced by clang is not “PNaCl-compatible”
• The one used by Rust, a fork of the clang LLVM.

What you (@DiamondLovesYou) did, is that you forked the Rust compiler so that it generates PNaCl compatible code.

So I guess, to have a reliable way to produce PNaCL code in Rust it remains to:

1. Merge the Rust LLVM into the standard one
2. Merge/improve the work on your fork into the main rust branch so that it becomes like a compiler option

The 1. point is a work in progress since rust becomes more stable, but there is no plan whatsoever on the 2.

Beside of that, we need the pepper API to communicate with Javascript, but I guess it’s just a wrapper of the C API so it’s the easier part.

I’m I right on all this ?

[DiamondLovesYou]

There is several LLVM codes :

• The “standard” one used by clang
• The one used by PNaCl which is in some sens is a subset of it, that’s why google gives a custom build-chain for C++, because the LLVM code produced by clang is not “PNaCl-compatible”
• The one used by Rust, a fork of the clang LLVM.

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.

What you (@DiamondLovesYou) did, is that you forked the Rust compiler so that it generates PNaCl compatible code.

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.

So I guess, to have a reliable way to produce PNaCL code in Rust it remains to:

1. Merge the Rust LLVM into the standard one
2. Merge/improve the work on your fork into the main rust branch so that it becomes like a compiler option

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).

Beside of that, we need the pepper API to communicate with Javascript, but I guess it’s just a wrapper of the C API so it’s the easier part.

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?

[DanielKeep]

To stick my head in: having poked around the NaCl SDK a bit in the past, I’d love to know how feasible it would be to create a simple plugin library that lets you load a PNaCl or even NaCl binary, and use it as a sandboxed library from Rust.

I don’t care about any of the HTML stuff; I just want to execute arbitrary code with a reasonable overhead.

[DiamondLovesYou]

To stick my head in: having poked around the NaCl SDK a bit in the past, I’d love to know how feasible it would be to create a simple plugin library that lets you load a PNaCl or even NaCl binary, and use it as a sandboxed library from Rust.

I don’t care about any of the HTML stuff; I just want to execute arbitrary code with a reasonable overhead.

Sandboxing is a process level construct. As in, it wouldn’t be sandboxed without a separate process to hold the PNaCl/NaCl module. Plus, you’d wouldn’t be able to just call functions like you would with a shared object, you’d have to implement an IPC protocol.

And that’s not even considering the sandbox itself.

[DanielKeep]

Oh, I know it’s process-based isolation. Obviously, some form of IPC would be necessary. But then, that’s how Pepper itself works.

[DiamondLovesYou]

Oh, I know it’s process-based isolation. Obviously, some form of IPC would be necessary. But then, that’s how Pepper itself works.

Oh okay, cool. I’m going to propose adding such a sandbox/etc so Servo can load and run PNaCl modules for this coming Google Summer of Code. Obviously that’s quite a tall order, so I’ll likely tackle it over several summers, starting with the sandbox using nexes (so no PNaCl).

If you don’t mind my asking, what is your desired use case?

[DanielKeep]

Two, one less theoretical than the other.

I wrote a modular, distributed microsimulation framework. One of the things I thought about early on was some way of loading arbitrary code into the workers through the controller, side-stepping problems around making sure all the nodes in the network have the same modules at the same versions, etc. Of course, security is a major issue with that.

The design really lends itself to the idea of putting the simulation modules in little sandboxes. Being able to just specify a bunch of pexes in the parameters would be awesome, especially for reproducibility!

The other idea was for a game engine with support for modding. As a kind of outgrowth of my simulation stuff, I’d love to build a game with a heavy emphasis on simulated systems. But that implies having efficient game code. PNaCl would solve more or less all the problem with that: mods wouldn’t be tied to specific platforms, the overhead would be acceptable, and users wouldn’t have to worry so much about safety.

More generally, I think secure, safe systems are just too damn hard to build. Anything that makes it easier would be great.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.