Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compiler: link .syso files found in Go package directories #4593

Draft
wants to merge 2 commits into
base: dev
Choose a base branch
from

Conversation

ydnar
Copy link
Contributor

@ydnar ydnar commented Nov 11, 2024

This is an experiment, driven by a need to link in custom sections into the resulting .wasm binary. Using a .syso file in a package directory is a well-known way to accomplish this with other architectures in big Go.

We have a POC that proves this works: ydnar/wasi-http-go#13

Another example: https://tip.golang.org/src/crypto/internal/boring/syso/

@dgryski co-authored this live at WasmCon.

Among other things, this enables WebAssembly programs to link in custom sections,
which can be stored in a relocatable wasm module with a .syso suffix in a package directory.

This will simplify the build process for WASI 0.2, removing the need to run
'wasm-tools component embed' with the original source WIT files.
@ydnar ydnar requested review from aykevl and dgryski November 11, 2024 19:52
@aykevl
Copy link
Member

aykevl commented Nov 12, 2024

While this is one option, I don't think we should be going for this solution. The reason is that .syso files would fundamentally be difficult to support in TinyGo, because existing .syso files will be expecting to use the Go calling convention (and not the TinyGo calling convention). So it would remain a wasm-only solution, which doesn't feel right to me (it feels like the wrong tool for the job).

Do you have any objections against a special-purpose pragma for this purpose? It would basically just add the file to the linker, nothing else.

Also, since this is going to be generated code and the uglyness is hidden, I don't see any fundamental reason why the #cgo hack couldn't be used? Certainly not pretty, no, but nobody except wasm-bindgen-go developers need to care about this. And it doesn't need any TinyGo changes as far as I can see.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants