Important Build Options

There are a few flags to control how binaries are built:

• -oOutput filename, see the build command.

• -targetSelect the target you want to use. Leave it empty to compile for the host. This switch also configures the emulator, flash tool and debugger to use so you don’t have to fiddle with those options. Read supported targets for a list of supported targets. Example targets:

  • wasmWebAssembly target. Creates .wasm files that can be run in a web browser.

  • arduinoCompile using the experimental AVR backend to run Go programs on an Arduino Uno.

  • microbitCompile programs for the BBC micro:bit <https://microbit.org/&gt;_.

  • qemuRun on a Stellaris LM3S as emulated by QEMU.

• -portSpecify the serial port used for flashing. This is used for the Arduino Uno, which is flashed over a serial port. It defaults to /dev/ttyACM0 as that is the default port on Linux.

• -optWhich optimization level to use. Optimization levels roughly follow standard -O level options like -O2, -Os, etc. Available optimization levels:

  • -opt=0Disable as much optimizations as possible. There are still a few optimization passes that run to make sure the program executes correctly, but all LLVM passes that can be disabled are disabled.

  • -opt=1Enable only a few optimization passes. In particular, this keeps the inliner disabled. It can be useful when you want to look at the generated IR but want to avoid the noise that is common in non-optimized code.

  • -opt=2A good optimization level for use cases not strongly limited by code size. Provided here for completeness. It enables most optimizations and will likely result in the fastest code.

  • -opt=sLike -opt=2, but while being more careful about code size. It provides a balance between performance and code size.

  • -opt=z (default)Like -opt=s, but more aggressive about code size. This pass also reduces the inliner threshold by a large margin. Use this pass if you care a lot about code size.

• -ocd-outputPrint output of the on-chip debugger tool (like OpenOCD) while in a tinygo gdb session. This can be useful to diagnose connection problems.

• -gcUse the specified memory manager:

  • -gc=noneDo not use a memory manager at all. This will cause a link error at every place in the program that tries to allocate memory. The primary use case for this is finding such locations.

  • -gc=dumbOnly allocate memory, never free it. This is the simplest allocator possible and uses very few resources while being very portable. Also, allocation is very fast. Larger programs will likely need a real garbage collector.

  • -gc=marksweepSimple conservative mark/sweep garbage collector. This collector does not yet work on all platforms. Also, the performance of the collector is highly unpredictable as any allocation may trigger a garbage collection cycle.

• -panicUse the specified panic strategy. That is, what the compiled program should do when a panic occurs.

  • -panic=abortPrint the panic message and abort the program. This is the default. On a desktop system this results in a call to abort. On WebAssembly this is implemented as the unreachable instruction. On microcontrollers, it results in a hang (endless loop).

  • -panic=trapDo not print the panic message but instead of printing anything, it directly hits a trap instruction. This instruction varies by platform but it will result in the immediate termination of the program. It could either exit with SIGILL or cause a call to the HardFault_Handler. It can be used to reduce the size of the compiled program while keeping standard Go safety rules intact at the cost of debuggability.