[PATCH] D43675: [WebAssembly] Rename imported/exported memory symbol to __linear_memory

Jacob Gravelle via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 2 10:02:13 PST 2018


jgravelle-google added a comment.

> I don't think we want to add a commandline flag for this. Better to pick a name and stick with it. If that's going to be "memory" - then fine. But there's no-one asking for it to be customised.

I agree, and I think "no one is asking for this" is an important point. I think if people ask for it in the future it will be something we can do, which is why I'm biased towards leaving this as-is for now.

> Surely just as many users will want to access the stack pointer (to pass things on the stack!) as will want to access the linear memory?

I don't think they will though. The use cases for passing things on the stack (that I can think of) are when the JS embedder wants to allocate new memory and pass that back to the wasm module, and in that case doing so via the stack is an optimization over using an exported (or JS-implemented) malloc/free.
On the flip side, a use case for reading memory external to the module that I can think of off the top of my head is converting a C string to a JS string. Or reading a vararg buffer from JS (which requires carnal enough knowledge of the ABI that you're a toolchain developer at this point :D )

> Only toolchain writers will do that

So in my head, I'm planning around a world where Clang+LLVM+LLD //is// the extent of the toolchain, and people write their minimal JS glue code themselves because it's small enough to avoid the overhead of some JS dependency to do it for them. For context, Hello World in Emscripten is has ~10K of minified JS glue code. Writing the JS glue by hand keeps both files combined under 1K.
So I'm interested in highly lightweight toolchains that reuse minimal JS glue, and in those contexts referencing the memory export by name will be nearly mandatory.

> It would be a shame to have the linker step outside of the reserved namespace and stomp on an unprefixed name, especially as the product is still unreleased. :)

All that is to say, having slept on it, you're right, and for the sanity of LLD on its own, creating a non-prefixed symbol is a bizarre design decision. It's not LLD's responsibility to be maximally ergonomic for highly specific use cases, and frankly as a user the difference between `exports.memory` and `exports.__linear_memory` isn't that weird or interesting. I still need to examine the wasm module that LLD produces to see what it's called either way, then I use whatever it is once in my program and call it done.

So, to reiterate, yeah `__linear_memory` is probably the right direction.


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D43675





More information about the llvm-commits mailing list