github
/
tinygo
mirror of https://github.com/tinygo-org/tinygo.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2241 Commits
99 Branches
41 Tags
26 MiB
Tree: 6234bf9a88
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '6234bf9a88'
${ noResults }
tinygo/targets/wasi.json

21 lines
440 B
Raw Normal View History

support WASI target (#1373) * initial commit for WASI support * merge "time" package with wasi build tag * override syscall package with wasi build tag * create runtime_wasm_{js,wasi}.go files * create syscall_wasi.go file * create time/zoneinfo_wasi.go file as the replacement of zoneinfo_js.go * add targets/wasi.json target * set visbility hidden for runtime extern variables Accodring to the WASI docs (https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md#current-unstable-abi), none of exports of WASI executable(Command) should no be accessed. v0.19.0 of bytecodealliance/wasmetime, which is often refered to as the reference implementation of WASI, does not accept any exports except functions and the only limited variables like "table", "memory". * merge syscall_{baremetal,wasi}.go * fix js target build * mv wasi functions to syscall/wasi && implement sleepTicks * WASI: set visibility hidden for globals variables * mv back syscall/wasi/* to runtime package * WASI: add test * unexport wasi types * WASI test: fix wasmtime path * stop changing visibility of runtime.alloc * use GOOS=linux, GOARCH=arm for wasi target Signed-off-by: mathetake <takeshi@tetrate.io> * WASI: fix build tags for os/runtime packages Signed-off-by: mathetake <takeshi@tetrate.io> * run WASI test only on Linux Signed-off-by: mathetake <takeshi@tetrate.io> * set InternalLinkage instead of changing visibility Signed-off-by: mathetake <takeshi@tetrate.io>
4 years ago
{
"llvm-target": "wasm32--wasi",
wasi: remove wasm build tag The wasm build tag together with GOARCH=arm was causing problems in the internal/cpu package. In general, I think having two architecture build tag will only cause problems (in this case, wasm and arm) so I've removed the wasm build tag and replaced it with tinygo.wasm. This is similar to the tinygo.riscv build tag, which is used for older Go versions that don't yet have RISC-V support in the standard library (and therefore pretend to be GOARCH=arm instead).
3 years ago
"build-tags": ["tinygo.wasm", "wasi"],
support WASI target (#1373) * initial commit for WASI support * merge "time" package with wasi build tag * override syscall package with wasi build tag * create runtime_wasm_{js,wasi}.go files * create syscall_wasi.go file * create time/zoneinfo_wasi.go file as the replacement of zoneinfo_js.go * add targets/wasi.json target * set visbility hidden for runtime extern variables Accodring to the WASI docs (https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md#current-unstable-abi), none of exports of WASI executable(Command) should no be accessed. v0.19.0 of bytecodealliance/wasmetime, which is often refered to as the reference implementation of WASI, does not accept any exports except functions and the only limited variables like "table", "memory". * merge syscall_{baremetal,wasi}.go * fix js target build * mv wasi functions to syscall/wasi && implement sleepTicks * WASI: set visibility hidden for globals variables * mv back syscall/wasi/* to runtime package * WASI: add test * unexport wasi types * WASI test: fix wasmtime path * stop changing visibility of runtime.alloc * use GOOS=linux, GOARCH=arm for wasi target Signed-off-by: mathetake <takeshi@tetrate.io> * WASI: fix build tags for os/runtime packages Signed-off-by: mathetake <takeshi@tetrate.io> * run WASI test only on Linux Signed-off-by: mathetake <takeshi@tetrate.io> * set InternalLinkage instead of changing visibility Signed-off-by: mathetake <takeshi@tetrate.io>
4 years ago
"goos": "linux",
"goarch": "arm",
"linker": "wasm-ld",
wasi: specify wasi-libc in a different way This way is more consistent with how picolibc is specified and allows generating a helpful error message. This error message should never be generated for TinyGo binary releases, only when doing local development.
4 years ago
"libc": "wasi-libc",
support WASI target (#1373) * initial commit for WASI support * merge "time" package with wasi build tag * override syscall package with wasi build tag * create runtime_wasm_{js,wasi}.go files * create syscall_wasi.go file * create time/zoneinfo_wasi.go file as the replacement of zoneinfo_js.go * add targets/wasi.json target * set visbility hidden for runtime extern variables Accodring to the WASI docs (https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md#current-unstable-abi), none of exports of WASI executable(Command) should no be accessed. v0.19.0 of bytecodealliance/wasmetime, which is often refered to as the reference implementation of WASI, does not accept any exports except functions and the only limited variables like "table", "memory". * merge syscall_{baremetal,wasi}.go * fix js target build * mv wasi functions to syscall/wasi && implement sleepTicks * WASI: set visibility hidden for globals variables * mv back syscall/wasi/* to runtime package * WASI: add test * unexport wasi types * WASI test: fix wasmtime path * stop changing visibility of runtime.alloc * use GOOS=linux, GOARCH=arm for wasi target Signed-off-by: mathetake <takeshi@tetrate.io> * WASI: fix build tags for os/runtime packages Signed-off-by: mathetake <takeshi@tetrate.io> * run WASI test only on Linux Signed-off-by: mathetake <takeshi@tetrate.io> * set InternalLinkage instead of changing visibility Signed-off-by: mathetake <takeshi@tetrate.io>
4 years ago
"cflags": [
"--target=wasm32--wasi",
all: use -opt flag for optimization level in CFlags (-Os, etc) This brings some consistency to the CFlags and fixes the issue that on some platforms (Linux, MacOS), no optimization level was set and therefore C files in packages were not optimized at all.
3 years ago
"--sysroot={root}/lib/wasi-libc/sysroot"
support WASI target (#1373) * initial commit for WASI support * merge "time" package with wasi build tag * override syscall package with wasi build tag * create runtime_wasm_{js,wasi}.go files * create syscall_wasi.go file * create time/zoneinfo_wasi.go file as the replacement of zoneinfo_js.go * add targets/wasi.json target * set visbility hidden for runtime extern variables Accodring to the WASI docs (https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md#current-unstable-abi), none of exports of WASI executable(Command) should no be accessed. v0.19.0 of bytecodealliance/wasmetime, which is often refered to as the reference implementation of WASI, does not accept any exports except functions and the only limited variables like "table", "memory". * merge syscall_{baremetal,wasi}.go * fix js target build * mv wasi functions to syscall/wasi && implement sleepTicks * WASI: set visibility hidden for globals variables * mv back syscall/wasi/* to runtime package * WASI: add test * unexport wasi types * WASI test: fix wasmtime path * stop changing visibility of runtime.alloc * use GOOS=linux, GOARCH=arm for wasi target Signed-off-by: mathetake <takeshi@tetrate.io> * WASI: fix build tags for os/runtime packages Signed-off-by: mathetake <takeshi@tetrate.io> * run WASI test only on Linux Signed-off-by: mathetake <takeshi@tetrate.io> * set InternalLinkage instead of changing visibility Signed-off-by: mathetake <takeshi@tetrate.io>
4 years ago
],
"ldflags": [
"--allow-undefined",
"--stack-first",
"--export-dynamic",
wasi: specify wasi-libc in a different way This way is more consistent with how picolibc is specified and allows generating a helpful error message. This error message should never be generated for TinyGo binary releases, only when doing local development.
4 years ago
"--no-demangle"
support WASI target (#1373) * initial commit for WASI support * merge "time" package with wasi build tag * override syscall package with wasi build tag * create runtime_wasm_{js,wasi}.go files * create syscall_wasi.go file * create time/zoneinfo_wasi.go file as the replacement of zoneinfo_js.go * add targets/wasi.json target * set visbility hidden for runtime extern variables Accodring to the WASI docs (https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md#current-unstable-abi), none of exports of WASI executable(Command) should no be accessed. v0.19.0 of bytecodealliance/wasmetime, which is often refered to as the reference implementation of WASI, does not accept any exports except functions and the only limited variables like "table", "memory". * merge syscall_{baremetal,wasi}.go * fix js target build * mv wasi functions to syscall/wasi && implement sleepTicks * WASI: set visibility hidden for globals variables * mv back syscall/wasi/* to runtime package * WASI: add test * unexport wasi types * WASI test: fix wasmtime path * stop changing visibility of runtime.alloc * use GOOS=linux, GOARCH=arm for wasi target Signed-off-by: mathetake <takeshi@tetrate.io> * WASI: fix build tags for os/runtime packages Signed-off-by: mathetake <takeshi@tetrate.io> * run WASI test only on Linux Signed-off-by: mathetake <takeshi@tetrate.io> * set InternalLinkage instead of changing visibility Signed-off-by: mathetake <takeshi@tetrate.io>
4 years ago
],
add wasm-abi field in TargetSpec && set generic for WASI by default (#1421) Signed-off-by: mathetake <takeshi@tetrate.io>
4 years ago
"emulator": ["wasmtime"],
"wasm-abi": "generic"
support WASI target (#1373) * initial commit for WASI support * merge "time" package with wasi build tag * override syscall package with wasi build tag * create runtime_wasm_{js,wasi}.go files * create syscall_wasi.go file * create time/zoneinfo_wasi.go file as the replacement of zoneinfo_js.go * add targets/wasi.json target * set visbility hidden for runtime extern variables Accodring to the WASI docs (https://github.com/WebAssembly/WASI/blob/master/design/application-abi.md#current-unstable-abi), none of exports of WASI executable(Command) should no be accessed. v0.19.0 of bytecodealliance/wasmetime, which is often refered to as the reference implementation of WASI, does not accept any exports except functions and the only limited variables like "table", "memory". * merge syscall_{baremetal,wasi}.go * fix js target build * mv wasi functions to syscall/wasi && implement sleepTicks * WASI: set visibility hidden for globals variables * mv back syscall/wasi/* to runtime package * WASI: add test * unexport wasi types * WASI test: fix wasmtime path * stop changing visibility of runtime.alloc * use GOOS=linux, GOARCH=arm for wasi target Signed-off-by: mathetake <takeshi@tetrate.io> * WASI: fix build tags for os/runtime packages Signed-off-by: mathetake <takeshi@tetrate.io> * run WASI test only on Linux Signed-off-by: mathetake <takeshi@tetrate.io> * set InternalLinkage instead of changing visibility Signed-off-by: mathetake <takeshi@tetrate.io>
4 years ago
}