This should avoid the rather frequent "test ran too long,
terminating..." error message that often occurs in CI and when running
`go test` manually. Apparently I was too optimistic: some tests take
longer than 1 second to run.
This is necessary for better CGo support on bare metal. Existing
libraries expect to be able to include parts of libc and expect to be
able to link to those symbols.
Because with this all targets have a working libc, it is now possible to
add tests to check that a libc in fact works basically.
Not all parts of picolibc are included, such as the math or stdio parts.
These should be added later, when needed.
This commit also avoids the need for the custom memcpy/memset/memcmp
symbols that are sometimes emitted by LLVM. The C library will take care
of that.
This refactor makes adding a new library (such as a libc) much easier in
the future as it avoids a lot of duplicate code. Additionally, CI should
become a little bit faster (~15s) as build-builtins now uses the build
cache.
Somehow I forgot to add this emulator. With this, you can easily emulate
programs:
$ tinygo run -target=atmega1284p examples/serial
Loaded 698 .text at address 0x0
Loaded 12 .data
hello world!..
hello world!..
hello world!..
This allows packages other than the compiler to know (from a single
source of truth) which implemenation is used for Go func values.
This refactor is necessary to be able to move the Optimize function to
the transform package.
Non-constant type asserts are not yet implemented, but should be
relatively easy to add at a later time. They should result in a clear
error message for now.
This convention is followed by most of the avr-gcc toolchain but older
versions of binutils don't mind overlapping program/data spaces.
However, newer versions start complaining about an overlap in address
space:
avr-ld: section .stack VMA [0000000000000100,00000000000002ff] overlaps section .text VMA [0000000000000000,0000000000000225]
This commit moves the data space in the linker script to 0x800000, like
the rest of the toolchain does.
This adds support for the `-scheduler=tasks` flag for AVR. On most AVR
chips you wouldn't want to run a real scheduler but it may be useful in
some cases, especially on devices with more RAM. It is disabled by
default.
This allows setting a different directory for experimental changes. For
example, I also have a llvm-project.master directory that tracks the
master branch. It is very useful to be able to temporarily use that
directory:
make llvm-build.master LLVM_BUILDDIR=llvm-build.master LLVM_PROJECT=llvm-project.master
Not tested on actual hardware, only on simavr. The main motivation for
adding this chip is to be able to run simulated tests using a much
larger memory space (16kB RAM, 128kB flash) without jumping to the XMega
devices that may not be as well supported by LLVM.
It does not appear to be necessary for these devices but might result in
more appropriate libraries to be linked in.
It is best to _not_ specify the exact MCU because otherwise a few other
settings (such as startfiles and some linker script configs) also get
set, which we do manually anyway and should not be interfered with.
I discovered this while working on support for the atmega1284.
Previously, the RAM was set to start at address 0. This is incorrect: on
AVR, the first few addresses are taken up by memory-mapped I/O. The
reason this didn't lead to problems (yet) was because the stack was
usually big enough to avoid real problems.
This commit switches integration tests to use the same error reporting
mechanism as the tinygo compiler normally uses. It replaces errors like
this:
main_test.go:139: failed to build: interp: branch on a non-constant
With this:
main.go:693: # math/rand
main.go:695: interp: branch on a non-constant
In this particular case the error isn't much better (it gives the
relevant package, though) but other errors should also include the
source location where they happen.
There were a few instances like `.text` and `.text*`. The first was
redundant with the second, but the intention was to write `.text.*`.
This doesn't change anything (tested with `make smoketest`) but should
avoid propagating this error in the future.
This patch is a combination of two related changes:
1. The compiler now allows other types than `int` when specifying the
size of a channel in a make(chan ..., size) call.
2. The compiler now checks for maximum allowed channel sizes. Such
checks are trivially optimized out in the vast majority of cases as
channel sizes are usually constant.
I discovered this issue when trying out channels on AVR.
The copy builtin is defined as follows by the Go language spec:
copy(dst, src []T) int
copy(dst []byte, src string) int
In other words, it returns an int. The runtime.sliceCopy compiler
intrinsic returned a uintptr instead, which led to a problem while
compiling the strings package for AVR.
No other architecture should be affected by this change as the
conversion from an uintptr to an int is a no-op on most architectures.
This fixes an error like the following:
E: The method driver /usr/lib/apt/methods/https could not be found.
N: Is the package apt-transport-https installed?
Apparently apt.llvm.org has been switched over to HTTPS. One solution
could be to install apt-transport-https, but another (easier) solution
is to switch to a newer container.
Note: I did not switch the other containers, to make sure TinyGo is
still built with an older Debian release. That ensures the resulting
binaries are relatively portable across distros, even relatively old
distros.
This makes the `make wasi-libc` command much more reliable and makes the
CI configuration simpler. Also, it avoids warnings when they are not
relevant.
Previously using defer with an exported function generated an invalid function call due to differences between TinyGo's calling convention and the C calling convention.
