Sam Clegg

@NWilson who has been working with me of the lld stuff.

After going back and forth a lot I've become pretty convinced that (2) is the best option. (1) might be possible as short term fix, but the emscripten-side fix could...

The downside (2) is that we are kind of going back on ourselves, having just moved away from using wasm globals to model data address in the object format, we...

The other downside of (2) is that it only works for relocations in the code section. Data section relocations will need to be applied at runtime. There is however already...

@Daniel-Abrecht, I think we already support what you want in terms on --allow-undefined. The linker will looks for a `.imports` file alongside any `.a` file it finds. This means --allow-undefined-file...

@NWilson, regarding the current state of emscripten, they reason this works is because emscripten itself creates the wasm memory object on the JS side, and controls where the stack and...

@Daniel-Abrecht I see what you mean and I think we share the same objective. I see this working via some kind of special library. So for example emscripten could provide,...

I agree that (1), could be the simplest way to go. I'm just a little worried about modifying emscripten at this low level, mostly because I'm not experienced and working...

I've been investigating replacing makeStaticAlloc() and simply putting the globals in C file. This has proved more complicated than intiially thought since emscripten doesn't have any way to export C...

Even if I great such wrapper functions I would then need to implicitly add them to EXPORTED_FUNCTIONS, otherwise they would be GC'd at link time. At least that is what...