PNaCl

[TurkeyMan]

Has anyone looked at Google's Native Client?
I have to write some NaCl software; it looks like Clang produces a normal .bc file and then their backend toolchain takes it from there.
Is there anything special about their PNaCl Clang, and the .bc it produces?
Has anybody looked into the work involved in supporting PNaCl in LDC?

[UplinkCoder]

PNaCl has a few special passes, i.e. for type legalisation.
I am all for supporting PNaCl. It should not be too hard. But I have to look at it a bit closer.

[TurkeyMan]

So there is some special gear between the frontend and the .bc output?
It'd be cool to have a working compiler, even if it only takes it as far as the .bc (the rest of the nacl toolchain can finish the job). And even if druntime isn't well supported, I can work without D's libraries. Still better than C++! ;)

[UplinkCoder]

I think the PNaCl backend handels the special stuff.

[TurkeyMan]

I am in a position where I may be able to get D adopted by my company if we have support for this.

Is there anything required by the front-end other than supporting -mtriple=le32-unknown-nacl and setting the proper build flags? (I guess pointer size, etc needs to be defined appropriately?)

If we can output a .bc with the proper build options, then Google's official PNaCl toolchain should be able to take it from there.

[dnadlinger]

I have never really dealt with PNaCl beyond experimenting with the official toolchain, but as far as I can see, the compiler backend side of things should be rather simple. Maybe the target setup code will need a bit of massaging from someone vaguely familiar with LLVM, but it shouldn't be too big of a roadblock as we don't really use any obscure LLVM bitcode features (beyond inline asm).

I'm not sure whether the PNaCl legalization passes are available as a standalone tool that takes standard LLVM IR as @UplinkCoder seems to suggest above. If not, you might have to build against Google's patched LLVM. But again, as we support a wide range of LLVM versions and don't really use any exotic APIs, this shouldn't be hard.

The much more cumbersome part will be to port druntime to this environment, especially if you want some level of support for GC and static constructors. Unless you have somebody that is comfortable with tackling this (or find somebody else who can spare the time to do so), I can't really advise trying to sell D for PNaCl support at this point.

[TurkeyMan]

I would have thought the legalisation passes would happen at the link step? I expect the easiest way to use LDC for these targets would be to use LDC to output .bc files, and then pipe them through Clang and the rest of the official toolchains to finish the job?

I am happy to have a crack at druntime ports if any of you LDC guys can make an experimental toolchain available. I can do useful work with '-betterc' (ie, no runtime) for now. We don't need the runtime up front. This will be for very small/light workloads initially, and we can workaround missing runtime features.

To get from frontent->bc, is it just a matter of configuring the target appropriately? Ie, supporting those triple's and giving proper pointer sizes and all that gear? What are the major complexities that usually appear at that level?

[Downchuck]

For a simple milestone, try getting the Hello Tutorial running.

There are some cpp interfaces:

#include "ppapi/cpp/instance.h"
#include "ppapi/cpp/module.h"
#include "ppapi/cpp/var.h"

And some hard coded extern names (namespace pp.CreateModule):
See:
Hello Tutorial source code
Part 1 of the NaCl Tutorial

[TurkeyMan]

I've tried this before, but I think I need an LDC build that supports the target.
I can compile .bc files from LDC and then try and link them with the NaCl toolchain, and I get

Linking two modules of different data layouts!
Linking two modules of different target triples: 'x86_64-pc-windows-msvc' and 'le32-unknown-nacl'

I have trouble imagining that the ABI will be compatible...

[TurkeyMan]

Then, of course, there's this:

ldctest/test.bc : error : undefined reference to '_Dmodule_ref'

Google refuses to reveal to me how to instruct the compiler to disable druntime. Something like walter's -better-c?

[HK47196]

Manu, are you still working on this?

Google refuses to reveal to me how to instruct the compiler to disable druntime.

the flag -defaultlib=

with nothing after it should disable druntime and phobos.

[TurkeyMan]

I wouldn't say I'm 'working' on it. I had a couple of cracks at fiddling with it, but I'm pretty sure it'll need a special build of LDC with some patches.
We could really make use of this though, it would go a long way towards getting D into my office...

[kinke]

Wikipedia:

On October 12, 2016, a comment on the Chromium issue tracker indicated that Google's Pepper and Native Client teams had been destaffed.[8] On May 30, 2017, Google announced deprecation of PNaCl in favor of WebAssembly.

=> Closing as part of house cleaning.