fmt.Println causes SIGSEGV with target=arduino

[directionless]

I'm not sure if this is a bug, or a limitation of the arduino platform:

func printOne() {
	fmt.Println("one")
}

func main() {
	f := printOne
	f()
}

Results in: (as run from a recently tiny-go docker container)

root@4aaf709538b5:/go/src/github.com/directionless/tiny-go-experiments# tinygo build -o test -target=arduino  ./func-pointers/
fatal error: unexpected signal during runtime execution
[signal SIGSEGV: segmentation violation code=0x1 addr=0x418 pc=0x7f7815ff6cdc]

runtime stack:
runtime.throw(0x842ef6, 0x2a)
	/usr/local/go/src/runtime/panic.go:617 +0x72
runtime.sigpanic()
	/usr/local/go/src/runtime/signal_unix.go:374 +0x4a9

goroutine 1 [syscall]:
runtime.cgocall(0x76ecb0, 0xc001065508, 0xc002bc73a8)
	/usr/local/go/src/runtime/cgocall.go:128 +0x5b fp=0xc0010654d8 sp=0xc0010654a0 pc=0x41ebfb
github.com/tinygo-org/tinygo/vendor/tinygo.org/x/go-llvm._Cfunc_LLVMTargetMachineEmitToMemoryBuffer(0x2d697d0, 0x2d7f340, 0xc000000001, 0xc002bc73a0, 0xc002bc73a8, 0xc000000000)
	_cgo_gotypes.go:8849 +0x4d fp=0xc001065508 sp=0xc0010654d8 pc=0x5efafd
github.com/tinygo-org/tinygo/vendor/tinygo.org/x/go-llvm.TargetMachine.EmitToMemoryBuffer.func1(0x2d697d0, 0x2d7f340, 0x1, 0xc002bc73a0, 0xc002bc73a8, 0x0)
	/go/src/github.com/tinygo-org/tinygo/vendor/tinygo.org/x/go-llvm/target.go:274 +0x18b fp=0xc001065548 sp=0xc001065508 pc=0x617ddb
github.com/tinygo-org/tinygo/vendor/tinygo.org/x/go-llvm.TargetMachine.EmitToMemoryBuffer(0x2d697d0, 0x2d7f340, 0x1, 0xc002bd21c0, 0x1b, 0x1)
	/go/src/github.com/tinygo-org/tinygo/vendor/tinygo.org/x/go-llvm/target.go:274 +0x84 fp=0xc0010655b0 sp=0xc001065548 pc=0x5fd624
github.com/tinygo-org/tinygo/compiler.(*Compiler).EmitObject(0xc00011a4e0, 0xc002bd21c0, 0x1b, 0xc002bd21c0, 0x1b)
	/go/src/github.com/tinygo-org/tinygo/compiler/compiler.go:2515 +0x4a fp=0xc001065600 sp=0xc0010655b0 pc=0x709d6a
main.Compile(0x7fff54d72eb1, 0x10, 0x7fff54d72e9e, 0x2, 0xc00013a160, 0xc001065f00, 0xc001065d88, 0x0, 0x0)
	/go/src/github.com/tinygo-org/tinygo/main.go:206 +0xbe9 fp=0xc001065d40 sp=0xc001065600 pc=0x75bfe9
main.Build(0x7fff54d72eb1, 0x10, 0x7fff54d72e9e, 0x2, 0x7fff54d72ea9, 0x7, 0xc000091f00, 0xc000104250, 0xc00010a200)
	/go/src/github.com/tinygo-org/tinygo/main.go:311 +0xe2 fp=0xc001065db0 sp=0xc001065d40 pc=0x75ed72
main.main()
	/go/src/github.com/tinygo-org/tinygo/main.go:604 +0xc74 fp=0xc001065f98 sp=0xc001065db0 pc=0x760a04
runtime.main()
	/usr/local/go/src/runtime/proc.go:200 +0x20c fp=0xc001065fe0 sp=0xc001065f98 pc=0x44943c
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1337 +0x1 fp=0xc001065fe8 sp=0xc001065fe0 pc=0x473b01

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
	/usr/local/go/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
	/usr/local/go/src/os/signal/signal_unix.go:29 +0x41

Works fine when called with -target=qemu

[aykevl]

This is a limitation of the AVR backend in TinyGo. It has many bugs and limitations being a relatively new backend that doesn't get as much love as it should. I don't think there is a lot we can do about that, except wait for it to improve (or help it improve).

[aykevl]

By the way, the issue here is probably the use of the fmt package. If you just use println for printing, things should improve.

[directionless]

Oh! You're right. The bug was fmt.Println vs println. Probably shouldn't be a SIGSEGV. I'll rename the bug.

simplest reproduction:

func main() {
	fmt.Println("sdf")
}

[niaow]

When building with a copy of LLVM with asserts on, we get some more information:

llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:9642: void llvm::SelectionDAGISel::LowerArguments(const llvm::Function&): Assertion `InVals.size() == Ins.size() && "LowerFormalArguments didn't emit the correct number of values!"' failed.

[niaow]

I think we hit some UB inside of LLVM, am adding some asserts into the relevant pass

[donleyp]

Hey, there! Is there a workaround for formatting numbers? I need to output numbers in binary and hexadecimal, not decimal. I am runninng on an ATMega2560

[dgryski]

This example no longer segfaults the compiler and #2389 is tracking the actual error message produced by the compiler.