7 ms·

Libc++ 9.0.0 adds explicit support for WASI

MuffinFlavored 7y ago
Say you have `shared_library.so` which exposes methods/APS `foo()` and `bar()` How would you load them/link against them + call them in Webassembly land?
- deleted 7y ago
  [deleted]
- pjmlp 7y ago
  By using dynamic loading capabilities of WebAssembly runtimes. Watch Lin Clark's closing keynote at RustConf 2019. https://www.youtube.com/watch?v=VlIydW5Fojw https://www.youtube.com/watch?v=VlIydW5Fojw
  - MuffinFlavored 7y ago
    Doesn't it kind of stink that there are so many WebAssembly runtimes? Fragmentation, different ways of doing things, etc.
    - kbenson 7y ago
      No? Would you prefer there was just one? That might make some things better, but it would make a great many things much worse, and make it much harder to fix them. Ideally we'll get to a few very good ones that are alle considered acceptable for most things that will steal good ideas from each other and experiment to find interesting ways forward. Nobody except their controlling entities really benefited in the long run from having IE as the vastly dominant browser, and I doubt we'll benefit from Chrome's emerging dominance to the same degree. IMHO, the compiler market was greatly benefited by the emergence of Clang as well. Competition is good.
    - krapp 7y ago
      No, this is what freedom and innovation looks like. Javascript has become mostly a lost cause as far as open source development goes, as it's basically owned and controlled by NPM Inc and corporate interests now, but WebAssembly at least still has the possibility of remaining open. At the very least, we should go through a period of experimentation by the community to settle on the best possible solutions (or sets of solution) and let things mature a bit, first. Now is not the time to bless a single runtime, package manager, etc.
      - pjmlp 7y ago
        WebAssembly is developed by the same corporations that own JavaScript.
        krapp 7y ago
        They don't own the runtime and package manager, though. Although Wasmer does come with a package manager (WAPM) that uses a proprietary registry like NPM, at least the developers have said they're committed to decentralized hosting[0]. Maybe someone can come up with a completely distributed package management alternative, which I would prefer, but at least Webassembly isn't yet at the degree of centralization that Javascript is. [0]https://news.ycombinator.com/item?id=19732794 https://news.ycombinator.com/item?id=19732794
        pjmlp 7y ago
        Which are utterly meaningless with the specification developed by said corporations. And really, the only thing going for WebAssembly is being the PNaCL that those corporations were willing to agree on.
        krapp 7y ago
        It's not the best possible scenario but "utterly meaningless" is hyperbole. Certainly it's better not to have every aspect of a language be centralized. It's already near impossible to distribute Javascript, or even software in many languages, without going through NPM. WebAssembly, thankfully, isn't there yet.
- coolspot 7y ago
  In my experience you will still have to compile your .so as wasm with exported methods.
mikece 7y ago
Is WASI (WebAssembly System Interface) a way to run WebAssembly outside of the browser on (theoretically) any device or is this a way to do systems programming in WebAssembly?
- CraftThatBlock 7y ago
  Yes, it's like the libc of WASM. https://wasmer.io https://wasmer.io is a runtime with WASI support
- phickey 7y ago
  Its an evolving standard set of system interfaces. Right now it supports sandboxed access to the filesystem via a POSIX-like api, as well as other basic interfaces like argv, environment variables, random numbers, and timers. https://wasi.dev https://wasi.dev
dmitrygr 7y ago
WebAssembly people continue to reinvent java, it seems
- wyldfire 7y ago
  I don't think Java bytecode was intended to be a portable representation targetable by any language. It was to be the representation for the Java language. Java applets have inferior sandboxing. [1] [1] https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...
  - pjmlp 7y ago
    Follow my sibling comment for examples all the way back to 1958. JVM yes was initially designed for Java alone, but its research successor, GraalVM, does understand LLVM bitcode thanks to Sulong. As for "superior" WebAssembly sandboxing, it doesn't protect against internal corruption, due to lack of bounds checking on memory access. Which allows for injected scripts to try to coerce a loaded module to change its behavior. No need to escape the sandbox, sometimes changing the outputs is all that an attack requires. It remains to be seen how many WebAssembly CVEs will appear when it starts to be more widely targeted by black hats. And if those WASI modules happen to be written in languages like C and C++, I expect a couple of them to show up.
    - zeroimpl 7y ago
      If WebAssembly is running in the browser, it’s not calling into C/C++ modules. If WebAssembly isn’t running in the browser, it doesn’t need to be sandboxed. Thus I don’t think we need to be concerned over WASI sand boxing in the same way as applets.
      - pjmlp 7y ago
        If JavaScript is calling into WebAssembly modules compiled from C and C++, naturally do we have to care about security. The existing model does not prevent exploits taking advantage of internal memory corruption inside the sandbox.
svnpenn 7y ago
I still dont understand the point of this. Why are people trying to turn JavaScript into a systems programming language? It isnt, has never been, and never will be that. If you wish to use a systems programming language, use a systems programming language. Plenty of old ones (Java, C, C++) and plenty of new ones (Go, D, Nim, Rust, Zig) are available. Its like people took a square piece of rock and said: A: hey, lets chip off some corners so that this can roll! B: but now its an octagon... A: well if you put it on a hill it can tumble down! All the while several styles of modern wheels sit behind them.
- krapp 7y ago
  Webassembly isn't Javascript? I mean, people probably are trying to do systems programming in Javascript, and I agree that's ridiculous, but this isn't an example of it. Webassembly is just a spec for a language agnostic bytecode. Despite it's name, it isn't even meant to run only in the browser.
  - gumby 7y ago
    > Webassembly is just a spec for a language agnostic bytecode. Despite it's name, it isn't even meant to run only in the browser. It's the same kind of namewashing as javascript's on name. Once more and we can call it a tradition!
- josephg 7y ago
  Uh, I think you have the metaphor the wrong way around. The goal of wasm / wasi isn’t to allow javascript to be a systems language. It’s to allow systems languages to be used in javascript, or allow them to interoperate with one another or run on different operating systems, or run on different hardware platforms. In javascript we’ve been stuck using octagon wheels but there’s all these new modern wheels sitting around that we haven’t been able to use because browsers could only run javascript. But now we have a way to fit the modern wheels on our javascript car.
  - snagglegaggle 7y ago
    But I gave you octagon wheels because I don't want you using real wheels.
bla3 7y ago
I'm not very familiar with WASI. For this to be useful for in-browser wasm apps, would browser wasm runtimes have to implement WASI too? If so, are any browsers looking at doing this? I do know that there are WASI runtimes for non-browser wasm applications.
- matthewbauer 7y ago
  I don't think this exists yet, but it is definitely possible to write a WASI runtime in pure JavaScript. A precursor to WASI, jfbastien's musl fork, had one: https://github.com/jfbastien/musl/blob/wasm-prototype-1/arch/wasm32/wasm.js https://github.com/jfbastien/musl/blob/wasm-prototype-1/arch...
matthewbauer 7y ago
Exceptions still don't work! That ends up making lots of C++ code not compilable.
- azakai 7y ago
  That's not a limitation of WASI - WASI is just the system APIs. Exceptions don't work natively in wasm yet, that's true. But they do work in wasm+JS (using JS exceptions for unwinding, in Emscripten).
  - matthewbauer 7y ago
    Yeah, Emscripten does support exceptions, but I don't think Emscripten creates WASI yet? It would be useful to separate out the exception handling from Emscripten to a runtime library so that other projects could use it, without relying on the entire Emscripten toolchain. I suspect we'll get exception handling at some point, but for now so much stuff just does not work without it. The whole idea of WASI is that it is not JavaScript-specific, so needing some JavaScript code just to get this basic feature is kind of surprising.
    - azakai 7y ago
      Emscripten does use some WASI APIs already, both normally and especially in standalone mode [1]. But yeah, for now WASI and wasm don't provide enough to do things like C++ exceptions, longjmp, etc., so Emscripten supports them using non-WASI APIs. Native exception handling for wasm is being worked on. If we don't want to wait for that, we could do exceptions using Asyncify [2]. But since we have the JS+wasm option for now, and native support coming, that's maybe not worth it. [1] https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone https://github.com/emscripten-core/emscripten/wiki/WebAssemb... [2] https://www.youtube.com/watch?v=qQOP6jqZqf8 https://www.youtube.com/watch?v=qQOP6jqZqf8

Say you have `shared_library.so` which exposes methods/APS `foo()` and `bar()` How would you load them/link against them + call them in Webassembly land?

deleted 7y ago
[deleted]
pjmlp 7y ago
By using dynamic loading capabilities of WebAssembly runtimes. Watch Lin Clark's closing keynote at RustConf 2019. https://www.youtube.com/watch?v=VlIydW5Fojw https://www.youtube.com/watch?v=VlIydW5Fojw
- MuffinFlavored 7y ago
  Doesn't it kind of stink that there are so many WebAssembly runtimes? Fragmentation, different ways of doing things, etc.
  - kbenson 7y ago
    No? Would you prefer there was just one? That might make some things better, but it would make a great many things much worse, and make it much harder to fix them. Ideally we'll get to a few very good ones that are alle considered acceptable for most things that will steal good ideas from each other and experiment to find interesting ways forward. Nobody except their controlling entities really benefited in the long run from having IE as the vastly dominant browser, and I doubt we'll benefit from Chrome's emerging dominance to the same degree. IMHO, the compiler market was greatly benefited by the emergence of Clang as well. Competition is good.
  - krapp 7y ago
    No, this is what freedom and innovation looks like. Javascript has become mostly a lost cause as far as open source development goes, as it's basically owned and controlled by NPM Inc and corporate interests now, but WebAssembly at least still has the possibility of remaining open. At the very least, we should go through a period of experimentation by the community to settle on the best possible solutions (or sets of solution) and let things mature a bit, first. Now is not the time to bless a single runtime, package manager, etc.
    - pjmlp 7y ago
      WebAssembly is developed by the same corporations that own JavaScript.
      - krapp 7y ago
        They don't own the runtime and package manager, though. Although Wasmer does come with a package manager (WAPM) that uses a proprietary registry like NPM, at least the developers have said they're committed to decentralized hosting[0]. Maybe someone can come up with a completely distributed package management alternative, which I would prefer, but at least Webassembly isn't yet at the degree of centralization that Javascript is. [0]https://news.ycombinator.com/item?id=19732794 https://news.ycombinator.com/item?id=19732794
        pjmlp 7y ago
        Which are utterly meaningless with the specification developed by said corporations. And really, the only thing going for WebAssembly is being the PNaCL that those corporations were willing to agree on.
        krapp 7y ago
        It's not the best possible scenario but "utterly meaningless" is hyperbole. Certainly it's better not to have every aspect of a language be centralized. It's already near impossible to distribute Javascript, or even software in many languages, without going through NPM. WebAssembly, thankfully, isn't there yet.
coolspot 7y ago
In my experience you will still have to compile your .so as wasm with exported methods.

mikece 7y ago

Is WASI (WebAssembly System Interface) a way to run WebAssembly outside of the browser on (theoretically) any device or is this a way to do systems programming in WebAssembly?

CraftThatBlock 7y ago
Yes, it's like the libc of WASM. https://wasmer.io https://wasmer.io is a runtime with WASI support
phickey 7y ago
Its an evolving standard set of system interfaces. Right now it supports sandboxed access to the filesystem via a POSIX-like api, as well as other basic interfaces like argv, environment variables, random numbers, and timers. https://wasi.dev https://wasi.dev

dmitrygr 7y ago

WebAssembly people continue to reinvent java, it seems

wyldfire 7y ago
I don't think Java bytecode was intended to be a portable representation targetable by any language. It was to be the representation for the Java language. Java applets have inferior sandboxing. [1] [1] https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...
- pjmlp 7y ago
  Follow my sibling comment for examples all the way back to 1958. JVM yes was initially designed for Java alone, but its research successor, GraalVM, does understand LLVM bitcode thanks to Sulong. As for "superior" WebAssembly sandboxing, it doesn't protect against internal corruption, due to lack of bounds checking on memory access. Which allows for injected scripts to try to coerce a loaded module to change its behavior. No need to escape the sandbox, sometimes changing the outputs is all that an attack requires. It remains to be seen how many WebAssembly CVEs will appear when it starts to be more widely targeted by black hats. And if those WASI modules happen to be written in languages like C and C++, I expect a couple of them to show up.
  - zeroimpl 7y ago
    If WebAssembly is running in the browser, it’s not calling into C/C++ modules. If WebAssembly isn’t running in the browser, it doesn’t need to be sandboxed. Thus I don’t think we need to be concerned over WASI sand boxing in the same way as applets.
    - pjmlp 7y ago
      If JavaScript is calling into WebAssembly modules compiled from C and C++, naturally do we have to care about security. The existing model does not prevent exploits taking advantage of internal memory corruption inside the sandbox.

svnpenn 7y ago

I still dont understand the point of this. Why are people trying to turn JavaScript into a systems programming language? It isnt, has never been, and never will be that. If you wish to use a systems programming language, use a systems programming language. Plenty of old ones (Java, C, C++) and plenty of new ones (Go, D, Nim, Rust, Zig) are available. Its like people took a square piece of rock and said: A: hey, lets chip off some corners so that this can roll! B: but now its an octagon... A: well if you put it on a hill it can tumble down! All the while several styles of modern wheels sit behind them.

krapp 7y ago
Webassembly isn't Javascript? I mean, people probably are trying to do systems programming in Javascript, and I agree that's ridiculous, but this isn't an example of it. Webassembly is just a spec for a language agnostic bytecode. Despite it's name, it isn't even meant to run only in the browser.
- gumby 7y ago
  > Webassembly is just a spec for a language agnostic bytecode. Despite it's name, it isn't even meant to run only in the browser. It's the same kind of namewashing as javascript's on name. Once more and we can call it a tradition!
josephg 7y ago
Uh, I think you have the metaphor the wrong way around. The goal of wasm / wasi isn’t to allow javascript to be a systems language. It’s to allow systems languages to be used in javascript, or allow them to interoperate with one another or run on different operating systems, or run on different hardware platforms. In javascript we’ve been stuck using octagon wheels but there’s all these new modern wheels sitting around that we haven’t been able to use because browsers could only run javascript. But now we have a way to fit the modern wheels on our javascript car.
- snagglegaggle 7y ago
  But I gave you octagon wheels because I don't want you using real wheels.

bla3 7y ago

I'm not very familiar with WASI. For this to be useful for in-browser wasm apps, would browser wasm runtimes have to implement WASI too? If so, are any browsers looking at doing this? I do know that there are WASI runtimes for non-browser wasm applications.

matthewbauer 7y ago
I don't think this exists yet, but it is definitely possible to write a WASI runtime in pure JavaScript. A precursor to WASI, jfbastien's musl fork, had one: https://github.com/jfbastien/musl/blob/wasm-prototype-1/arch/wasm32/wasm.js https://github.com/jfbastien/musl/blob/wasm-prototype-1/arch...

matthewbauer 7y ago

Exceptions still don't work! That ends up making lots of C++ code not compilable.

azakai 7y ago
That's not a limitation of WASI - WASI is just the system APIs. Exceptions don't work natively in wasm yet, that's true. But they do work in wasm+JS (using JS exceptions for unwinding, in Emscripten).
- matthewbauer 7y ago
  Yeah, Emscripten does support exceptions, but I don't think Emscripten creates WASI yet? It would be useful to separate out the exception handling from Emscripten to a runtime library so that other projects could use it, without relying on the entire Emscripten toolchain. I suspect we'll get exception handling at some point, but for now so much stuff just does not work without it. The whole idea of WASI is that it is not JavaScript-specific, so needing some JavaScript code just to get this basic feature is kind of surprising.
  - azakai 7y ago
    Emscripten does use some WASI APIs already, both normally and especially in standalone mode [1]. But yeah, for now WASI and wasm don't provide enough to do things like C++ exceptions, longjmp, etc., so Emscripten supports them using non-WASI APIs. Native exception handling for wasm is being worked on. If we don't want to wait for that, we could do exceptions using Asyncify [2]. But since we have the JS+wasm option for now, and native support coming, that's maybe not worth it. [1] https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone https://github.com/emscripten-core/emscripten/wiki/WebAssemb... [2] https://www.youtube.com/watch?v=qQOP6jqZqf8 https://www.youtube.com/watch?v=qQOP6jqZqf8