Skip to content

Question: Best way to share malloc/free in multiple modules? #579

Description

@konsumer

I have an example project that allows me to load multiple modules and share malloc/free (by implementing it in the host and sharing memory and a few other globals.)

I would like to do similar, but be able to use all of wasi-libc, so I can write "mostly just libc" code that shares memory between multiple modules.

What is the best way to do this? I have tried these so far:

  • import malloc/free and some memory things into every module. This currently works, but for the rest of libc, I'd need to wrap all the wasi stuff, duplicating the work here. I wrote a stub that implements some libc stuff, and imports wasi and malloc/free. I am not a very experienced C programmer, though, and the idea of maintaining my own libc seems a bit daunting. Is there a define or something that says "use all WASI preview2 imports, but import malloc/free instead of implement it" in wasi-libc? (maybe something with MALLOC_IMPL?)
  • export wasi-libc's malloc/free & mem from 1 module, and share with others. I tried this, and could not really get it working. Each other module that uses wasi-libc also wants to implement it's own malloc/free and they do not load together. I may have set this up wrong, so if this is the right way to do it, help with building this would be appreciated

Activity

  1. changed the title [-]Question: Best way to share malloc/free?[/-] [+]Question: Best way to share malloc/free in multiple modules?[/+] on Apr 7, 2025
  2. sunfishcode commented on Apr 10, 2025

    @sunfishcode
    Member

    The closest thing would be wasi-sdk's currently experimental implementation of "dynamic" libraries. If you build with -fPIC and link with -shared, you can produce ".so" files. That said, you'll need a way to link the dynamic libraries together. If you're building a component, you can use wasm-tools component link. Otherwise, you may find the information here helpful for explaining how these libraries work and what would be needed to link them together.

  3. konsumer commented on Apr 11, 2025

    @konsumer
    Author

    If you build with -fPIC and link with -shared, you can produce ".so" files.

    I was doing this (see the working Makefile but I think the part I was missing was how to link them together, properly. The idea here for me is that I want to put the shared code (for example, my game engine and wasi-libc) in a seperate wasm loaded in host, then load the user's game, so they don't need to include all that in every game, rather than link it all together as one thing, to create the game (like static-linking works fine, but produces a lot of duplication.)

    Otherwise, you may find the information here helpful

    Yep, I followed that document's pattern to get my test project working. I may not have done it right, but that was the idea.

    As I said, I did get it working with shared mem, the main prob was multiple definitions of malloc (if I load several wasi-sdk wasms) but otherwise it seems to work ok.

    I tried this :

    WASM_IMPORT(malloc) void* malloc(size_t size);
    WASM_IMPORT(free) void free(void* ptr);
    
    #define MALLOC_IMPL malloc
    #define FREE_IMPL free
    
    #include <stdlib.h>

    If I build with this:

    -fPIC -shared -Wl,--experimental-pic -Wl,--import-memory
    

    I get this error at runtime:

    [LinkError: WebAssembly.instantiate(): Import #5 "env" "sprintf": function import requires a callable]
    

    If I compile with

    -Wl,--import-memory
    

    It all builds/runs fine, but doesn't seem to be copying the memory correctly (like my tests don't output the right stuff.)

    You can see that on this branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions