Followup: could this somehow be related to function pointers to C runtime functions? E.g. spine-c memory allocations calls all go through functions pointers:
https://github.com/EsotericSoftware/spine-runtimes/blob/933ccbba6244cd8aefb04dadf8324be2442eb858/spine-c/spine-c/src/spine/extension.c#L37-L43 ...it all works fine (with emmalloc and optimizations) if I simply bypass this entire code by wiring the spine-c allocation macros directly to malloc, calloc, realloc and free (here: https://github.com/EsotericSoftware/spine-runtimes/blob/933ccbba6244cd8aefb04dadf8324be2442eb858/spine-c/spine-c/include/spine/extension.h#L69-L91). ...which works for me ATM, but it would still be good to get to the bottom of this issue. On Saturday, 3 September 2022 at 17:03:59 UTC+2 Floh wrote: > Ok, it gets weirder: > > If I add the -sEXPORTED_FUNCTIONS=_calloc, the sample links alright, but > then doesn't run. There's no crash message on the JS console either, it > just sits there with a black screen. > > This time it's the same behaviour in release and debug mode, yet debug > mode works alright without the EXPORTED_FUNCTIONS option (because it builds > with -O0, which triggers the problem). > > Ok, that's enough "rabbit-holeing" for today. My options for this > particular sample currently seem to be: > > (1) don't use emmalloc > (2) don't build with optimizations enabled > > ...both options suck TBH ;) > On Saturday, 3 September 2022 at 16:44:41 UTC+2 Floh wrote: > >> PPPS: building with "-sEXPORTED_FUNCTIONS=_calloc" also works, but I >> don't understand why I need this only for this one specific sample, for a >> problem triggered by a library that doesn't even call calloc. I didn't have >> to deal with EXPORTED_FUNCTIONS for years (instead EMSCRIPTEN_KEEPALIVE did >> the job), and especially never for any C runtime functions. >> >> Any ideas of what's the issue here would be greatly appreciated. I'll put >> the EXPORTED_FUNCTIONS into my build options as a hack for now, but it >> would be nice if that wouldn't be needed (especially since I don't >> understand the reason, lol). >> >> Cheers! >> >> On Saturday, 3 September 2022 at 16:26:07 UTC+2 Floh wrote: >> >>> Another information tidbit: >>> >>> Adding a calloc() call in any of the other (very similar) samples always >>> works without problems (e.g. I don't need to add calloc to >>> EXPORTED_FUNCTIONS as advised by the emsdk linker - I don't use >>> EXPORTED_FUNCTIONS anywhere in my compiler settings). >>> >>> It also works if I remove any calls to that spine-c library in my own >>> code (but mind that the spine-c library doesn't call into calloc - emsdk's >>> llvm-nm doesn't show any references to calloc in the resulting library). >>> >>> The only place where I can find a reference to calloc is as 'weak >>> symbol' in libemmalloc.a, but I don't understand how any potential problems >>> in emmalloc would be triggered by the presence or absence of a random third >>> party library that doesn't even call into calloc... >>> >>> On Saturday, 3 September 2022 at 15:54:37 UTC+2 Floh wrote: >>> >>>> Ok, it works if I change one thing: setting the -O flag from -O3 to -O0 >>>> (-O1 also already breaks). >>>> >>>> ...also it seems that calloc *is* actually called somewhere (the wasm >>>> crashes in the calloc stub when I build with >>>> ERROR_ON_UNDEFINED_SYMBOLS=0). >>>> But I still think it's not anywhere in my code (e.g. the Spine runtime has >>>> CALLOC macros all over the place, but this resolves to a call to a helper >>>> function with malloc+memset. >>>> >>>> >>>> On Saturday, 3 September 2022 at 15:21:18 UTC+2 Floh wrote: >>>> >>>>> PPS: ...looks like I can only go back to SDK version 3.0.0 on ARM >>>>> Macs, and the problem already existed in that version. >>>>> >>>>> On Saturday, 3 September 2022 at 15:16:42 UTC+2 Floh wrote: >>>>> >>>>>> PS: this is the wasm-ld cmdline: >>>>>> >>>>>> em++: error: >>>>>> '/Users/floh/projects/fips-sdks/emsdk/upstream/bin/wasm-ld -o >>>>>> /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-vscode-release/spine-sapp.wasm >>>>>> >>>>>> sapp/CMakeFiles/spine-sapp.dir/spine-sapp.c.obj >>>>>> sapp/CMakeFiles/spine-sapp.dir/spine-assets.c.obj libs/sokol/libsokol.a >>>>>> libs/spine-c/libspine-c.a libs/stb/libstb.a libs/util/libfileutil.a >>>>>> fips-cimgui_cimgui/libcimgui.a >>>>>> -L/Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto >>>>>> >>>>>> -lGL-webgl2 -lal -lhtml5 -lstubs -lc -lcompiler_rt -lc++-noexcept >>>>>> -lc++abi-noexcept -lemmalloc -lc_rt -lsockets -mllvm >>>>>> -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj >>>>>> -mllvm >>>>>> -disable-lsr >>>>>> --allow-undefined-file=/var/folders/dz/g9ydwg8973z9nn5bvffcwf3h0000gn/T/tmphqvycm26.undefined >>>>>> >>>>>> --strip-debug --export-if-defined=main --export-if-defined=stackSave >>>>>> --export-if-defined=stackRestore --export-if-defined=stackAlloc >>>>>> --export-if-defined=__wasm_call_ctors >>>>>> --export-if-defined=__errno_location >>>>>> --export-if-defined=malloc --export-if-defined=free >>>>>> --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm >>>>>> --export-table -z stack-size=5242880 --initial-memory=33554432 >>>>>> --entry=main >>>>>> --max-memory=2147483648 --global-base=1024' failed (returned 1) >>>>>> >>>>>> ...I'm now trying to bisect the SDK version to see if this is a >>>>>> regression... >>>>>> >>>>>> On Saturday, 3 September 2022 at 15:03:21 UTC+2 Floh wrote: >>>>>> >>>>>>> I just stumbled over a very weird problem in a new sample for my >>>>>>> sokol headers which includes a non-trivial 3rd party C library - the >>>>>>> spine-c runtime ( >>>>>>> https://github.com/EsotericSoftware/spine-runtimes/tree/4.1/spine-c/spine-c >>>>>>> ) >>>>>>> >>>>>>> When building in release mode (but not in debug mode) the linker >>>>>>> complains about an unresolved 'calloc' call. Adding detailed output >>>>>>> via LLD_REPORT_UNDEFINED=1 I get tons of: >>>>>>> >>>>>>> wasm-ld: error: >>>>>>> /Users/floh/projects/fips-sdks/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libemmalloc.a(emmalloc.o): >>>>>>> >>>>>>> undefined symbol: calloc >>>>>>> >>>>>>> ... how does that even make sense when emmalloc is supposed to >>>>>>> provide an implementation of calloc... anyway... >>>>>>> >>>>>>> The error goes away when compiling in debug mode (some differences >>>>>>> that come to mind to the release mode is that debug mode doesn't use >>>>>>> -flto, >>>>>>> and also doesn't run the closure compiler). >>>>>>> >>>>>>> The problem also goes away when not building with emmalloc. >>>>>>> >>>>>>> Now the weird thing is that the entire code this sample is built >>>>>>> from doesn't appear to call calloc anywhere... and that other samples >>>>>>> which >>>>>>> actually use calloc build just fines. >>>>>>> >>>>>>> Has anybody seen a similar problem yet, before I jump myself into >>>>>>> the rabbit hole? :) >>>>>>> >>>>>>> The problematic command line is: >>>>>>> >>>>>>> em++ -s DISABLE_EXCEPTION_CATCHING=1 -fno-exceptions -fno-rtti >>>>>>> -fstrict-aliasing -Wall -Wno-multichar -Wextra -Wno-unknown-pragmas >>>>>>> -Wno-ignored-qualifiers -Wno-long-long -Wno-overloaded-virtual >>>>>>> -Wno-deprecated-writable-strings -Wno-unused-volatile-lvalue >>>>>>> -Wno-inconsistent-missing-override -Wno-warn-absolute-paths >>>>>>> -Wno-expansion-to-defined -flto -O3 -DNDEBUG -s >>>>>>> DISABLE_EXCEPTION_CATCHING=1 --memory-init-file 0 -s >>>>>>> INITIAL_MEMORY=33554432 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s >>>>>>> NO_EXIT_RUNTIME=1 -s LLD_REPORT_UNDEFINED=1 -s ALLOW_MEMORY_GROWTH=1 -s >>>>>>> USE_WEBGL2=1 -s "MALLOC='emmalloc'" -s NO_FILESYSTEM=1 -s WASM=1 >>>>>>> --shell-file /Users/floh/projects/sokol-samples/webpage/shell.html -O3 >>>>>>> -flto --closure 1 -s ASSERTIONS=0 >>>>>>> sapp/CMakeFiles/spine-sapp.dir/spine-sapp.c.obj >>>>>>> sapp/CMakeFiles/spine-sapp.dir/spine-assets.c.obj -o >>>>>>> /Users/floh/projects/fips-deploy/sokol-samples/sapp-webgl2-wasm-vscode-release/spine-sapp.html >>>>>>> >>>>>>> libs/sokol/libsokol.a libs/spine-c/libspine-c.a libs/stb/libstb.a >>>>>>> libs/util/libfileutil.a fips-cimgui_cimgui/libcimgui.a >>>>>>> >>>>>> -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/20539dff-8fa2-4d8d-9f36-eec9d3fbf8cdn%40googlegroups.com.
