Thanks for that info. With that and digging in the code, I think I've got a better understanding of why malloc support would be challenging.
It looks like an asm.js/WASM memory is laid out like (data segment) + (staticAlloc space) + (stack) + (dynamicAlloc space) + (mallocable heap). The dynamicAlloc space seems to be for data that comes in before the runtime initializes, like the filesystem stuff you mentioned. I believe other code calling allocate or getMemory before initialization would also hit this. Stack space is configurable via the module object. If we added something like STATIC_PREALLOC_SIZE. That would fix the size of the staticAlloc space, as well as use it for any dynamicAllocs (possibly introducing the chance dynamicAllocs fails). If a user built with both TOTAL_STACK and STATIC_PREALLOC_SIZE, then binaryen would be able to would be able to compute the same DYNAMIC_TOP as the actual invocation. On Tuesday, August 21, 2018 at 1:02:03 PM UTC-7, Alon Zakai wrote: > > I think malloc is something neither the asm.js nor wasm ctor evallers > support currently (asm.js code looks like it allows using DYNAMICTOP_PTR, > but if the value there changes, we fail to eval that ctor). In both cases, > the tricky thing is to turn the malloc into a fully static allocation, > which needs some care as the location of dynamically allocated memory is > not always set at compile time (we allow static allocations during startup, > like for the filesystem - this is something we could reconsider). > > Re-ordering should work, yeah. In asm2wasm we currently just have the list > of constructors, so we'd need to also preserve their priorities after LLVM, > but that doesn't seem too hard. For the wasm backend, I believe they are > all collapsed into a single ctor anyhow, so that model would need to change > to allow such optimization. > > On Mon, Aug 20, 2018 at 5:58 PM Charles Vaughn <[email protected] > <javascript:>> wrote: > >> Looking into why EVAL_CTORs isn't helping with my project, I've come >> across a limitation that seems to only exist for WASM, not asm.js. Notably >> some of the initializers in my project invoke malloc (I believe by way of >> shared pointer initialization). It looks like malloc invokes sbrk (which is >> explicitly disallowed by the asm.js ctor_evaller). In the case of binaryen >> this fails by way of sbrk trying to access DYNAMICTOP_PTR, which ends up as >> a '...stopping since could not eval: tried to access a dangerous >> (import-initialized) global: global$0' >> >> It does seem like something that could be handled, and would be a big win >> for more dynamic initialization type scenarios. I believe it works when >> targetting asm.js as that handles its memory allocation differently. >> >> Another point is that constructor evaluation order is flexible. I know >> there is some machinery to control initializer ordering, which may limit >> this approach in cases where it does matter, but it's possible for the >> constructor evaluator to re-order constructors so that eval-able ones are >> moved to the front of the execution list. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
