daneelsan / minimal-zig-wasm-canvas Goto Github PK

In build.zig it sets the global-base to 6560.

// https://github.com/ziglang/zig/issues/8633
lib.global_base = 6560;

As far as I know, setting global-base is used to reserve part of the memory.

For example, in tic80's (a fantasy console) example zig project's build.zig, they do this:

// all the memory below 96kb is reserved for TIC and memory mapped I/O
// so our own usage must start above the 96kb mark
lib.global_base = 96 * 1024;

https://github.com/joshgoebel/TIC-80/blob/main/templates/zig/build.zig

That makes sense, we dont want the stack or the heap to touch those first 96 * 1024 bytes because thats were the tic runtime will put all the runtime necessary information.

But in this project, there is no such thing, so I feel like global-base should be set to 0? What am I missing?

Have been scouring for something like this. Excellent work.

When building with recent versions of Zig, the build first fails with wasm-ld: --global-base may not be used with -shared/-pie. After removing the line that sets global base in build.zig, the build appears to succeed except it will fail to run in browsers (tested with Firefox and Chromium).

In the Firefox console, '__memory_base' is not a Number is the error given, Chromium gives a similar error. It appears that this can be partially remedied by setting some values in the script.js file, which I will add below:

var importObject = {
    env: {
        consoleLog: (arg) => console.log(arg), // Useful for debugging on zig's side

        memory: memory,

        __memory_base: 0,

        // TODO: where to start stack pointer?
        __stack_pointer: new WebAssembly.Global({
            value: "i32",
            mutable: true
        }, 0),

        __indirect_function_table: new WebAssembly.Table({
            initial: 0,
            maximum: 0,
            element: 'anyfunc'
        }),

        __table_base: 0,
    },
};

Setting these values in the importObject section appear to make this specific example now work, although it seems incredibly hacky and doesn't function correctly with a more complex personal project of mine, so it probably shouldn't just be accepted as a solution without further investigation.

What changed in Zig to change this behavior? It appears that if this project is not rebuilt after cloning, it will run as intended, so whatever now has to be manually set in the js file was once in the wasm binary itself.

Hi,

With the proposed WASM memory settings (128 KBytes), wasm-ld can't build the binaries:

zig build checkerboard -Drelease=true --verbose
/usr/local/Cellar/zig/0.10.0/bin/zig build-lib /projects/git/minimal-zig-wasm-canvas/checkerboard.zig -OReleaseSmall --cache-dir /projects/git/minimal-zig-wasm-canvas/zig-cache --global-cache-dir /.cache/zig --name checkerboard -dynamic --import-memory --initial-memory=131072 --max-memory=131072 --global-base=6560 -target wasm32-freestanding-musl -mcpu generic --enable-cache 
LLD Link... wasm-ld: error: initial memory too small, 1055392 bytes needed

So I had to set 17 pages.

zig build checkerboard -Drelease=true --verbose
/usr/local/Cellar/zig/0.10.0/bin/zig build-lib /projects/git/minimal-zig-wasm-canvas/checkerboard.zig -OReleaseSmall --cache-dir /projects/git/minimal-zig-wasm-canvas/zig-cache --global-cache-dir /.cache/zig --name checkerboard -dynamic --import-memory --initial-memory=1114112 --max-memory=1114112 --global-base=6560 -target wasm32-freestanding-musl -mcpu generic --enable-cache

How did you do to make it fit in 2 pages?

Note: I'm using Zig 0.10.0 on MacOS