Memory management

[kripken]

WebAssembly provides a native stack for function calls and local variables, and aside from that, a linear memory which you can read and write to. The linear memory can be used for data that is function-scope but cannot live in a local variable (because it's address is taken, for example), and for heap allocations and everything else.

WebAssembly and Binaryen by themselves provide nothing on top of that, so mir2wasm could build functionality as needed using the linear memory. For example, the stack pointer could be stored at address 8, and we could emit code in function prologues etc. to read it, bump it, etc. etc.

Alternatively, if we assume the output will be integrated with emscripten, it can provide some support here, for example it would provide a malloc implementation as part of libc.

I'm not sure how rust code works in terms of heap allocations. If it uses its own code for malloc, maybe we would just compile that over. Or if it assumes a libc with a malloc, then maybe integrating with emscripten is easier.

[kripken]

To focus the question, the issue is how functional rust output is without libc.

If it can work well without it, I would suggest focusing on standalone output, and ignore emscripten integration for now. Things could be simpler that way, one less component to think about.

However, if rust output requires libc to be useful, then we could integrate emscripten soon and get libc easily that way.

[lqd]

cc @eddyb :)

[brson]

Rust can do a whole lot without libc (we can translate all of libcore without needing to think about libc or malloc), and mir2wasm shouldn't need much (if any) awareness of the emscripten runtime.

I guess we need to define this shadow stack for values whose address is taken. That's a good near-term task.