Re: Trying to understand invoke_* wrappers
They are generated for exception handling support. You can pass '-s DISABLE_EXCEPTION_CATCHING=1' to emcc, but I think this is already the default, so I'm not sure why you are getting that. On Wed, Oct 10, 2018 at 11:20 AM stephen.weber via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > Hello! > > I am trying to compile some C code with emscripten to use with a > non-browser WASM VM, so I can't use the generate JS shims and have to fill > in anything actually needed on my own. The bulk of what I need after an > `-O3` is not a big deal (Math.pow and such) but all of the invoke_* > wrappers have me stumped. What are these wrappers for? Will calling a > WASM C function from another WASM C function, even via pointer, ever > generate a JavaScript exception (in the browser context)? If not, is there > any way to tell emcc "hey, this is all C code here" or something and have > the `invoke_*` wrappers not be used? > > -- > 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. > -- 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.
Trying to understand invoke_* wrappers
Hello! I am trying to compile some C code with emscripten to use with a non-browser WASM VM, so I can't use the generate JS shims and have to fill in anything actually needed on my own. The bulk of what I need after an `-O3` is not a big deal (Math.pow and such) but all of the invoke_* wrappers have me stumped. What are these wrappers for? Will calling a WASM C function from another WASM C function, even via pointer, ever generate a JavaScript exception (in the browser context)? If not, is there any way to tell emcc "hey, this is all C code here" or something and have the `invoke_*` wrappers not be used? -- 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.
Re: Removal of EMSCRIPTEN_ROOT from config file
Does this fix change the behaviour of the the "--em-config" and "--cache" cmdline args of emcc and emar to point to a local emscripten SDK install? For me it's important that I don't have that "one and only" central emscripten SDK, but separate versions per "workspace", and I'm using the "--em-config" and "--cache" to isolate those different SDKs (I'm not setting any environment variables like EM_CONFIG or EMSCRIPTEN_ROOT either btw). As long as the cmdline args continue working, I guess I'm fine with the change. Cheers! -Floh. On Wednesday, 10 October 2018 02:41:26 UTC+2, Sam Clegg wrote: > > TLDR: There is a field in called EMSCRIPTEN_ROOT in the config file > which in theory can be used by external tools to find the "active" > emscripten. I'm proposing to remove it. > > --- > > Maintaining this field has a cost and it can get out of sync with the > emscripten you are actually using.Imagine you run `emcc` and if > parses the config file and finds EMSCRIPTEN_ROOT pointing to different > version of emscripten. > > The two current users of EMSCRIPTEN_ROOT that I know of are the scons > support: > > https://github.com/kripken/emscripten/blob/incoming/tools/scons/site_scons/site_tools/emscripten/emscripten.py > > And ammo.js: https://github.com/kripken/ammo.js/blob/master/make.py#L17 > > In both of these cases a better solution would be either: > 1) looks for `emcc` in the $PATH > 2) check for EMSCRIPTEN_ROOT in the environment. > > Parsing the config file is also a rather brittle solution, and > prevents us from iterating on the config file format and how its > parses. It also uses python's `eval` which is nasty. > > Any objections to following this path? > -- 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.
Re: Stability of llvm-lto
I'm compiling all my stuff with "--llvm-lto 1" and haven't seen problems so far, so from my point of view it's robust. My code isn't very complex but at least the Oryol samples have a nice assortment of 3rd party libs (e.g. Bullet Physics and several UI frameworks): http://floooh.github.io/oryol-samples/index.html https://floooh.github.io/tiny8bit/ On Wednesday, 10 October 2018 00:09:15 UTC+2, Corey Lucier wrote: > > We really wish to lean on LLVM link time optimizations. > > The Emscripten docs say . "LLVM LTO is not perfectly stable yet, and can > cause code to behave incorrectly.". > > Does this note still apply? There's nothing saying what particular > scenarios are problematic and I can't find equivalent docs in the LLVM > project itself. > > So...are you guys actively discouraging it's use? > > Thanks, > > Corey > -- 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.
Re: Removal of EMSCRIPTEN_ROOT from config file
Hi, I believe we'd need to deal with LLVM_ROOT as well, since the fastcomp version needs to be in sync with emscripten's? - Sylvain On 10/10/2018 02:41, Sam Clegg wrote: > TLDR: There is a field in called EMSCRIPTEN_ROOT in the config file > which in theory can be used by external tools to find the "active" > emscripten. I'm proposing to remove it. > > --- > > Maintaining this field has a cost and it can get out of sync with the > emscripten you are actually using.Imagine you run `emcc` and if > parses the config file and finds EMSCRIPTEN_ROOT pointing to different > version of emscripten. > > The two current users of EMSCRIPTEN_ROOT that I know of are the scons support: > https://github.com/kripken/emscripten/blob/incoming/tools/scons/site_scons/site_tools/emscripten/emscripten.py > And ammo.js: https://github.com/kripken/ammo.js/blob/master/make.py#L17 > > In both of these cases a better solution would be either: > 1) looks for `emcc` in the $PATH > 2) check for EMSCRIPTEN_ROOT in the environment. > > Parsing the config file is also a rather brittle solution, and > prevents us from iterating on the config file format and how its > parses. It also uses python's `eval` which is nasty. > > Any objections to following this path? > -- 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.
