`strip = "symbols"` breaks wasm code

[SUPERCILEX]

strip = "symbols" seems to remove needed code because my wasm app does nothing. However, strip = "debuginfo" works.

rustc 1.60.0-nightly (1bd4fdc94 2022-01-12)
binary: rustc
commit-hash: 1bd4fdc943513e1004f498bbf289279c9784fc6f
commit-date: 2022-01-12
host: x86_64-unknown-linux-gnu
release: 1.60.0-nightly
LLVM version: 13.0.0

[ehuss]

@SUPERCILEX Can you provide a minimal example that demonstrates where stripping symbols causes a problem? Which target are you using?

cc @alexcrichton and/or @joshtriplett in case you are interested.

[SUPERCILEX]

@ehuss Sure, here you go: https://github.com/SUPERCILEX/bevy-vs-pixi/tree/42332e37a72b5403f85fe57a40feb70b2e1dc6e2. You'll notice that nothing happens if you run it. However, if you go into the Cargo.toml and change strip = true to strip = "debuginfo", things start working again.

[alexcrichton]

My guess as to what's happening here is that this isn't a bug in rustc but it's a theoretical bug in wasm-bindgen. I forget where but I think wasm-bindgen sometimes relies on the name section, and with -Cstrip=symbols that's getting omitted and wasm-bindgen is tricked into thinking there's nothing in the module.

From what I can tell though there's not an issue with rustc here.

[SUPERCILEX]

Should this issue be moved to wasm-bindgen? Or should cargo simply fail to accept strip=symbols when targeting wasm32?

[alexcrichton]

Personally I don't think it's worthwhile to leave the issue here. I would recommend digging in more to figure things out before opening a new issue.

[lukechu10]

Ah it's because __wbindgen_start gets renamed when the binary is stripped, making nothing happen because wasm-bindgen thinks it's a library, not a binary.

[SUPERCILEX]

@alexcrichton Would updating rustc to pass in a --keep-symbol=__wbindgen_start flag be a reasonable solution? Or is there a better way to prevent __wbindgen_start from being stripped?

[bjorn3]

Can you strip the executable after running wasm-bindgen?