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

[Nicholas Wilson via Phabricator via llvm-commits]

ncw added a comment.

Some more thoughts - 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. If we went down that route, for consistency we'd have to add a commandline flag for all the linker-created symbols; `__linear_memory` is really no different to `__stack_pointer`.

a) I personally find it odd that we use the string `"__linear_memory"` in the object files, then change it to `"memory"` in LLD. But, we use the string `"__stack_pointer"` in both object file and linked output. That's clearer.
b) 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? So if you're expecting people to be typing `"__linear_memory"` in their code, surely you should also be concerned about them typing `"__stack_pointer"`.

In fact though, I don't think it's a correct expectation that people will be using the memory export //by its export name//. Only toolchain writers will do that, in order to wrap the ArrayBuffer in a TypedArray for applications to use. That's how it is currently in Emscripten - there is no user or code that's using that `"memory"` string (and it's not even available in asm.js mode, I don't think), the name of the Wasm export is entirely hidden from application code.  Instead it's all done through helpers on the `Runtime` object or using TypedArray globals `HEAP8`. LLD could import/export the memory under any name it chooses, as long as Emscripten knows where to put it; it really don't end up polluting any user code, at least in the way Emscripten currently works. I'd expect that to hold for other toolchains too, since the raw WebAssembly.Memory object is virtually never going to be used without going through some toolchain-provided TypedArray.

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


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D43675