Trying to understand invoke_* wrappers

[stephe...@shopify.com]

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?

[Heejin Ahn]

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 <emscripte...@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-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stephen Weber]

Adding `-s DISABLE_EXCEPTION_CATCHING=1` to cflags did not have an effect.  I have looked into it more and it seems my C code *is* using longjmp which this is also used for in the normal emscripten target -- perhaps it is detecting that and turning it back on anyway?  Since I'm using an alternate VM I'll need to write my own longjmp implementation, but it won't need (or benefit from, since go has no native exception mechanism) the invoke_* wrappers so I'd still like to be able to disable their generation if possible.

You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/jyLsB0b6j70/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

singpolyma.net

[Heejin Ahn]

Could you dump you .emscripten file and command line option used?

[Sam Clegg]

If you only want to build a pure wasm module you might want to try
just using the clang+lld directly. We recently transitioned to be a
default architecture if llvm so you can build wasm modules directly
with "clang --target=wam32". You will need to a recent build of
clang and llvm.

On the matter of the invoke_ functions, I believe they can are
generated when you use either exceptions or setjmp/longjmp