This shows nicely formatted error messages for missing symbol names and
for out-of-flash, out-of-RAM conditions (on microcontrollers with
limited flash/RAM).
Unfortunately the missing symbol name errors aren't available on Windows
and WebAssembly because the linker doesn't report source locations yet.
This is something that I could perhaps improve in LLD.
The C printf function is sometimes needed for C files included using
CGo. This commit makes sure they're available on all systems where CGo
is fully supported (that is, everywhere except on AVR).
For baremetal systems using picolibc, I've picked the integer-only
version of printf to save on flash size. We might want to consider
providing a way to pick the floating point version instead, if needed.
It's possible to detect the architecture from the target triple, but
there are a number of exceptions that make it unpleasant to use for this
purpose. There are just too many weird exceptions (like mips vs mipsel,
and armv6m vs thumv6m vs arm64 vs aarch64) so it's better to centralize
these to canonical architecture names.
I picked the architecture names that happen to match the musl
architecture names, because those seem the most natural to me.
This adds the same panic locations that are already present for
`tinygo flash -monitor`, but for `tinygo run` and `tinygo test`.
For example, this is the output that I get while working on some GC
code. It now shows the source location instead of just an address:
$ tinygo test -v archive/zip
=== RUN TestReader
=== RUN TestReader/test.zip
panic: runtime error at 0x000000000024d9b4: goroutine stack overflow
[tinygo: panic at /home/ayke/src/tinygo/tinygo/src/internal/task/task_stack.go:58:15]
FAIL archive/zip 0.139s
(This particular location isn't all that useful, but it shows that the
feature works).
These libraries will be automatically built when needed and cached.
The main reason these were needed is for play.tinygo.org, but I've now
prebuilt them there directly (so they don't need to be built for every
tarball).
* reflect: rawFieldByNameFunc: copy index slice to avoid later overwrites
* runtime: Simplify slice growing/appending code
Refactor the slice appending function to rely on the slice growing
function, and remove branches/loops to use a branchfree variant.
Signed-off-by: L. Pereira <l.pereira@fastly.com>
* runtime: Remove one branch in sliceAppend()
Both branches were equivalent, so guard the overall logic in
sliceAppend() with the more general condition.
Signed-off-by: L. Pereira <l.pereira@fastly.com>
* runtime: Simplify slice growing calculation
Use `bits.Len()` rather than `32 - bits.LeadingZeros32()`. They're
equivalent, but the Len version is a bit easier to read.
Signed-off-by: L. Pereira <l.pereira@fastly.com>
* reflect: Always call sliceGrow() in extendSlice()
sliceGrow() will return the old slice if its capacity is large enough.
Signed-off-by: L. Pereira <l.pereira@fastly.com>
---------
Signed-off-by: L. Pereira <l.pereira@fastly.com>
Co-authored-by: Damian Gryski <damian@gryski.com>
For some reason, the type kind name is "unsafe.Pointer" while the
.Name() method just returns "Pointer".
Not sure why this difference exists, but to be able to test .Name() in
testdata/reflect.go it needs to match.
This improves compilation performance by about 5% in my quick test,
while increasing binary size on average by 0.13% when comparing the
smoke tests in the drivers repo (and about two thirds of that 0.13% is
actually caused by a single smoke test).
I think this is a good idea because it aligns the TinyGo optimization
sequence with what ThinLTO expects.
This adds linux/mipsle (little endian Mips) support to TinyGo.
It also adds experimental linux/mips (big-endian) support. It doesn't
quite work yet, some parts of the standard library (like the reflect
package) currently seem to assume a little-endian system.
Previously, the error messages could be shown out of order.
With this patch, the errors are sorted before being shown to the user.
This makes it easier to read the error messages, and matches what the
`go` toolchain does.
This is a refactor, which should (in theory) not change the behavior of
the compiler. But since this is a pretty large change, there is a chance
there will be some regressions. For that reason, the previous commits
added a bunch of tests to make sure most error messages will not be
changed due to this refactor.
This is just one optimizer pass that's easy to test for. There are
others, but I'm ignoring them for now.
The one other that would be reasonable to test is when starting a
goroutine with -gc=none, but I'm leaving that one for another time.
Match the error messages in testdata/errors/*.go like LLVM FileCheck,
which includes regular expressions.
I believe this is much more flexible, and LLVM uses it in nearly all of
their tests so it must work quite well for compilers.
- add internal/wasm-tools/go.mod file to depend on wasm-tools-go
- copy package cm into src/internal/cm
- remove wasm-tools-go "vendor" submodule
internal/tools: fix typo
go.{mod,sum}, internal/tools: add wit-bindgen-go to tools
GNUmakefile: use go run for wit-bindgen-go
GNUmakefile: add tools target to go:generate tools binaries in internal/tools
GNUmakefile: add .PHONY for lint and spell
GNUmakefile, internal/cm: vendor package cm into internal/cm
go.{mod,sum}: update wasm-tools-go to v0.1.4
internal/wasi: use internal/cm package
remove submodule src/vendor/github.com/ydnar/wasm-tools-go
GNUmakefile: add comment documenting what wasi-cm target does
go.{mod,sum}: remove toolchain; go mod tidy
go.mod: revert to Go 1.19
go.mod: go 1.19
go.{mod,sum}, internal/{tools,wasm-tools}: revert root go.mod file to go1.19
Create a wasm-tools specific module that can require go1.22 for wasm-tools-go.
Compilers like GCC keep adding new checks that produce new warnings.
Sometimes it can be false positives.
Do not treat such warnings in binaryen library as errors. tinygo won't
be able to provide zero warnings in its dependencies.
Closes#4332
This is done at a later time anyway, so doesn't need to be done in the
cgo package. In fact, _not_ doing it there makes it easier to print
correct relative packages.
This is needed for some improvements I'm going to make next.
This commit also refactors error handling slightly to make it more
easily testable, this should hopefully not result in any actual changes
in behavior.
Go code might sometimes want to use preprocessor macros that were passed
on the command line. This wasn't working before and resulted in the
following error:
internal error: could not find file where macro is defined
This is now supported, though location information isn't available
(which makes sense: the command line is not a file).
I had to use the `clang_tokenize` API for this and reconstruct the
original source location. Apparently this is the only way to do it:
https://stackoverflow.com/a/19074846/559350
In the future we could consider replacing our own tokenization with the
tokenizer that's built into Clang directly. This should reduce the
possibility of bugs a bit.
Uses a vendored "internal/diff" from Big Go to show the differences
between the expected and actual outputs when tests fail.
Signed-off-by: L. Pereira <l.pereira@fastly.com>
Wasm linear memory is always initialized to zero by definition,
so there's no need to waste time zeroing out this allocation. This
is the case for freshly-obtained memory from mmap().
Signed-off-by: L. Pereira <l.pereira@fastly.com>
* internal/wasi: update to wasm-tools-go@v0.1.1
See https://github.com/ydnar/wasm-tools-go/releases/tag/v0.1.1 for additional information.
* internal/wasi: update to wasm-tools-go@v0.1.2
* internal/wasi: regenerate with wasm-tools-go@v0.1.3
It assumed the maximum alignment was equal to sizeof(void*), which is
definitely not the case. So this only worked more or less by accident
previously.
It now uses the alignment as specified by the frontend, or else
`unsafe.Alignof(complex128)` which is typically the maximum alignment of
a given platform (though this shouldn't really happen in practice: the
optimizer should keep the 'align' attribute in place).
This adds something like 'align 4' to the runtime.alloc calls, so that
the compiler knows the alignment of the allocation and can optimize
accordingly.
The optimization is very small, only 0.01% in my small test. However, my
plan is to read the value in the heap-to-stack transform pass to make it
more correct and let it produce slightly more optimal code.
This means it's possible to test just a particular OS/arch with a
command like this:
go test -run=Build -target=linux/arm
I found it useful while working on MIPS support.
Ayke van Laethem
Kobayashi Shunta
leongross
L. Pereira
Laurent Demailly
deadprogram
Matthew Hiles
Randy Reddig
Tai Groot
Anatol Pomozov
Dmitry Shemin
Elias Naur
Damian Gryski