I will say the largest source of native vs. asm.js breaking differences I've found have been due to initializer order. Depending on it is undefined, but it sucks to have tests pass on the x86 build, but crash in the asm.js one. I've got a tool that reverses the order of __ATINIT__ to quickly check this.
On Thursday, February 15, 2018 at 11:34:59 AM UTC-8, Alon Zakai wrote: > > I don't think there's an option for minifying the names of global ctors > currently. Usually there are few so it was never an urgent priority like > minifying other things. > > Instead of adding that, it might be simpler to just export a single > function that calls them all. (I used to think there was value in exporting > them separately, as it allows the outside more control, but I don't think > I've ever seen a concrete case where that happens.) > > On Tue, Feb 13, 2018 at 7:22 AM, Lorenzo Wölckner <lorenzo....@gmail.com > <javascript:>> wrote: > >> Also, specifying --llvm-opts "['-O3', '-internalize']" doesn't seem to >> do anything, and using --llvm-opts "['-O3', '-strip']" causes the >> `asm2wasm` step to then fail with: >> >> `Fatal: duplicate function: $_` >> >> On Tuesday, February 13, 2018 at 3:49:41 PM UTC+1, Lorenzo Wölckner wrote: >>> >>> Hello everyone, >>> >>> I am a bit lost at the moment regarding the correct way to really fully >>> strip all symbol information for the final resulting .js plus .wasm library. >>> In my C++ project I set all the needed flags in cmake for the first >>> "compilation from C++ to LLVM bitcode" step, including -O3 >>> -fvisibility=hidden -fvisibility-inlines-hidden -DNDEBUG, I also try to >>> strip symbols on linking. >>> In the second "compilation from bitcode to WASM" step I also set all the >>> related flags that I could find like -O3 --llvm-lto 3 --llvm-opts "['-O3']". >>> >>> In the resulting .js file however I noticed that there are >>> many __GLOBAL__sub_I_ExampleClassNameHere_cpp variables (which are then >>> used inside __ATINIT__ for global initialization). >>> This exposes all the names of my library's classes. >>> Trying to use the EVAL_CTORS=1 flags doesn't work as it cannot eval some >>> of the functions: >>> DEBUG:root:trying to eval __GLOBAL__I_000101 >>> ...stopping since could not eval: call import: env.invoke_i >>> >>> Is there some flag or setting I forgot in either of the compilation >>> steps to be able to correctly strip/hide symbols for these remaining global >>> initializers and not expose the internals of my original C++ library? >>> It's ok for all of these to be called but I would like to have >>> masked/obfuscated/minified names for them... >>> >>> Thanks in advance for the help. >>> >> -- >> 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 emscripten-discuss+unsubscr...@googlegroups.com <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 emscripten-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
