Ok, ticket is here: https://github.com/emscripten-core/emscripten/issues/17808
Let me know if I can help with anything else :) On Tuesday, 6 September 2022 at 20:30:55 UTC+2 [email protected] wrote: > Yes, please file a ticket. > > I think the solution is going to be to set `force_object_files = True` on > `libmalloc` in `tools/system_libs.spy`.. which means it (like compiler-rt > et al) will be compiled as normal object files and not take part in LTO. > > I am curious why this doesn't happen for dlmalloc too though.. > > cheers, > sam > > On Tue, Sep 6, 2022 at 10:19 AM Floh <[email protected]> wrote: > >> Ok, I could cobble together a surprisingly simple reproducer here: >> >> https://github.com/floooh/emsc-calloc-emmalloc-repro >> >> -flto is indeed needed. So the 4 ingredients are: >> >> 1. malloc+memset being 'optimized' to a call to calloc via -O1 or better >> 2. ...where malloc is called through a function pointer >> 3. ...and emmalloc is used instead of the vanilla allocator >> 4. ...and -flto must be enabled >> >> ...if any of this is missing, it works :D >> >> Should I write an Emscripten ticket too? >> On Tuesday, 6 September 2022 at 18:43:52 UTC+2 Floh wrote: >> >>> Part of the mystery can be solved because clang replaces malloc+memset >>> pairs with a single calloc call (only when optimization is enabled): >>> >>> https://www.godbolt.org/z/8r3Ydjs6a >>> >>> ...which explains why the problem shows up in release mode, but not >>> debug mode. >>> >>> There still must be something else going on though, because I'm using >>> the malloc+memset combo all the time together with emmalloc (and I guess >>> the missing piece is that the malloc call is going through the function >>> pointer). >>> >>> I'll tinker around a bit more with compiler options (but since this is a >>> library, I cannot dictate what compiler options the code is built with). >>> >>> Cheers! >>> >>> On Monday, 5 September 2022 at 19:31:17 UTC+2 [email protected] wrote: >>> >>>> The other thing this could be related to is LTO. IIUC LTO itself can >>>> generate calls to buildin functions (such as malloc and calloc) that are >>>> not present in the original program. Does disabling LTO fix the problem? >>>> >>>> On Mon, Sep 5, 2022 at 10:28 AM Sam Clegg <[email protected]> wrote: >>>> >>>>> Can you trying building with `-Wl,--trace-symbol=calloc` rather than >>>>> `LLD_REPORT_UNDEFINED=1` (I guess there are still some issues with that >>>>> setting). >>>>> >>>>> Does the link time error tell you why calloc is being pulled in? (The >>>>> JS compiler linker errors should do this but they often just say "top >>>>> level >>>>> C/C++"). >>>>> >>>>> On Sat, Sep 3, 2022 at 6:03 AM Floh <[email protected]> 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/c47cee25-6e4b-4fbe-9f6f-0d7da7e02562n%40googlegroups.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/c47cee25-6e4b-4fbe-9f6f-0d7da7e02562n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >> 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/f761c696-9943-474d-8bd8-6bccb0667f37n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/emscripten-discuss/f761c696-9943-474d-8bd8-6bccb0667f37n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/dae5aec2-78b1-4cd8-8572-710b96da3ffdn%40googlegroups.com.
