Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Draft
ydnar wants to merge2 commits intotinygo-org:dev
base:dev
Choose a base branch
Loading
fromydnar:ydnar/syso

Conversation

ydnar
Copy link
Contributor

@ydnarydnar commentedNov 11, 2024
edited
Loading

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.

xplshn reacted with thumbs up emoji
@aykevl
Copy link
Member

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.

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 added a commit to bytecodealliance/go-modules that referenced this pull requestNov 30, 2024
@ydnar
Copy link
ContributorAuthor

The Cgo hack can’t be used because it creates a circular dependency on packagesyscall.

What if I limited this PR to justwasm32?

@aykevl
Copy link
Member

The Cgo hack can’t be used because it creates a circular dependency on packagesyscall.

Yeah, you're right.

What if I limited this PR to justwasm32?

Limiting to wasm would indeed help against my worries. Or even only accepting a single filename (I don't know, something likewasi-component.syso) so that the intended use is very clear. It's easy to lift such restrictions in the future if needed, but adding them in the future may be difficult if people started using these .syso files for other purposes.

@ydnar
Copy link
ContributorAuthor

One complication: -Target=wasip2 sets GOARCH=arm GOOS=linux.

This means that foo_wasm.syso would not be found.

Do you have any plans to change the GOARCH/GOOS handling for architectures that TinyGo supports that Go doesn't?

ydnar added a commit to bytecodealliance/go-modules that referenced this pull requestDec 3, 2024
ydnar added a commit to bytecodealliance/go-modules that referenced this pull requestDec 6, 2024
This enables WIT tree-shaking by world or interface, as a precursor for Go package-level component metadata.wit/bindgen: oopswit/bindgen: add WIT generation for each WIT interface (Go package)Currently disabled.wit/bindgen: cgo + linker tricks WIPwit: fix typowit/bindgen: typowit: type aliases force transitive dependency on the dependencies of their parent interfacewit: prepare for filtering interface contentswit: remove ConstrainTointernal/wasm: stub linking sectionwit/bindgen: generate .wasm.syso files in each Go packageCurrently stubbed out (if false). Depends ontinygo-org/tinygo#4593wit: revise package sorting algorithmThis enables wasi:http to sort before wasi:cli.wit/bindgen: more cleanup (path -> pkgPath)wit/bindgen: optionally generate WIT files for each Go packagecmd/wit-bindgen-go: --generate-wit option to generate WIT files for each Go packagewit/bindgen: generate synthetic worlds in the go:bindgen package namespace
@aykevl
Copy link
Member

Do you have any plans to change the GOARCH/GOOS handling for architectures that TinyGo supports that Go doesn't?

We can't, really. We usego list to get a list of files to compile. So we have to pretend to be something that the standard library supports (such as linux/arm). Because wasip1 support exists in the stdlib, we can use the actual GOOS/GOARCH values, but sadly that's not the case for wasip2.

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

@aykevlaykevlAwaiting requested review from aykevl

@dgryskidgryskiAwaiting requested review from dgryski

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@ydnar@aykevl

[8]ページ先頭

©2009-2025 Movatter.jp