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.
2490 Commits
99 Branches
41 Tags
26 MiB
Tree: f9f2349850
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'f9f2349850'
${ noResults }
tinygo/targets/wasi.json

20 lines
448 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
{
build: normalize target triples to match Clang This commit changes a target triple like "armv6m-none-eabi" to "armv6m-unknown-unknow-eabi". The reason is that while the former is correctly parsed in Clang (due to normalization), it wasn't parsed correctly in LLVM meaning that the environment wasn't set to EABI. This change normalizes all target triples and uses the EABI environment (-eabi in the triple) for Cortex-M targets. This change also drops the `--target=` flag in the target JSON files, the flag is now added implicitly in `(*compileopts.Config).CFlags()`. This removes some duplication in target JSON files. Unfortunately, this change also increases code size for Cortex-M targets. It looks like LLVM now emits calls like __aeabi_memmove instead of memmove, which pull in slightly more code (they basically just call the regular C functions) and the calls themself don't seem to be as efficient as they could be. Perhaps this is a LLVM bug that will be fixed in the future, as this is a very common occurrence.
3 years ago
"llvm-target": "wasm32-unknown-wasi",
targets: add CPU property everywhere This is for consistency with Clang, which always adds a CPU flag even if it's not specified in CFLAGS. This commit also adds some tests to make sure the Clang target-cpu matches the CPU property in the JSON files. This does have an effect on the generated binaries. The effect is very small though: on average just 0.2% increase in binary size, apparently because Cortex-M3 and Cortex-M4 are compiled a bit differently. However, when rebased on top of https://github.com/tinygo-org/tinygo/pull/2218 (minsize), the difference drops to -0.1% (a slight decrease on average).
3 years ago
"cpu": "generic",
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",
internal/task: use asyncify on webassembly This change implements a new "scheduler" for WebAssembly using binaryen's asyncify transform. This is more reliable than the current "coroutines" transform, and works with non-Go code in the call stack. runtime (js/wasm): handle scheduler nesting If WASM calls into JS which calls back into WASM, it is possible for the scheduler to nest. The event from the callback must be handled immediately, so the task cannot simply be deferred to the outer scheduler. This creates a minimal scheduler loop which is used to handle such nesting.
3 years ago
"scheduler": "asyncify",
"default-stack-size": 8192,
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
}