Issue Using Multiple Goroutines on Pi Pico

[AcousticTypewriter]

Hey there!

I've been having some issues using goroutines for my raspberry pi pico. I am completely stuck from this bug. It seems there's an llvm problem compiling my code, and after some googling, I was unable to find anything related.

Here's a simplified version of my code that still produces the error: [https://gist.github.com/AcousticTypewriter/4c94db8053aa8f6e8cdc5e6b5b3f4c8c]

(In actuality, instead of a random number determining which goroutine is triggered, its based off of a button press)

Here's my command:
tinygo build -target=pico main.go

Here's the error:
invalid llvm.used member i32 ptrtoint (ptr @"main.elevatorYO$gowrapper" to i32) LLVM ERROR: Broken module found, compilation aborted! error: failed to link /tmp/tinygo2939992984/main: signal: aborted (core dumped)

I'm compiling using debian.

Any ideas? I'm not sure if this is a problem using multiple goroutines or if there's something else.

I'm relatively new to tinygo and golang, so any help would be appreciated.

Cheers!

[deadprogram]

I run multiple goroutines on rp2040 processors frequently, so probably not that. For example see https://github.com/hybridgroup/tinyglobo/blob/main/main.go

[AcousticTypewriter]

@deadprogram I've narrowed the problem down to having multiple conditional goroutines that don't trigger consistently. That code example doesn't have that I believe.

[aykevl]

I can reproduce the compiler crash. Here is the relevant stacktrace:

tinygo: /home/ayke/src/tinygo/tinygo/llvm-project/llvm/include/llvm/Support/Casting.h:578: decltype(auto) llvm::cast(From*) [with To = Constant; From = Value]: Assertion `isa<To>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
SIGABRT: abort
PC=0xfffeece02790 m=11 sigcode=18446744073709551610
signal arrived during cgo execution

goroutine 46 [syscall]:
runtime.cgocall(0x801170, 0x40181dd888)
        /usr/local/go1.21.0/src/runtime/cgocall.go:157 +0x44 fp=0x40181dd840 sp=0x40181dd800 pc=0x481bc4
tinygo.org/x/go-llvm._Cfunc_LLVMConstPointerCast(0xfffe5512a9a0, 0xfffe60170e30)
        _cgo_gotypes.go:3362 +0x34 fp=0x40181dd880 sp=0x40181dd840 pc=0x694f34
github.com/tinygo-org/tinygo/compiler/llvmutil.AppendToGlobal.ConstPointerCast.func10({0x0?}, {0x0?})
        /home/ayke/pkg/mod/tinygo.org/x/go-llvm@v0.0.0-20221028183034-8341240c0b32/ir.go:983 +0x84 fp=0x40181dd8d0 sp=0x40181dd880 pc=0x6ec524
tinygo.org/x/go-llvm.ConstPointerCast(...)
        /home/ayke/pkg/mod/tinygo.org/x/go-llvm@v0.0.0-20221028183034-8341240c0b32/ir.go:983
github.com/tinygo-org/tinygo/compiler/llvmutil.AppendToGlobal({0x40181ddb40?}, {0x54809ad, 0x9}, {0x400a95aa80, 0x3, 0x0?})
        /home/ayke/src/tinygo/tinygo/compiler/llvmutil/llvm.go:218 +0x210 fp=0x40181dd9c0 sp=0x40181dd8d0 pc=0x6ec1e0
github.com/tinygo-org/tinygo/transform.CreateStackSizeLoads({0xfffe6002b5d0?}, 0x40000c46c0)
        /home/ayke/src/tinygo/tinygo/transform/stacksize.go:98 +0x8e8 fp=0x40181dddf0 sp=0x40181dd9c0 pc=0x7a0b48
github.com/tinygo-org/tinygo/builder.Build.func5(0x0)
        /home/ayke/src/tinygo/tinygo/builder/build.go:580 +0x538 fp=0x40181ddf60 sp=0x40181dddf0 pc=0x7b3fc8
github.com/tinygo-org/tinygo/builder.runJob(0x40042d9ec0, 0x0?)
        /home/ayke/src/tinygo/tinygo/builder/jobs.go:222 +0x48 fp=0x40181ddfb0 sp=0x40181ddf60 pc=0x7c0a78
github.com/tinygo-org/tinygo/builder.runJobs.func2()
        /home/ayke/src/tinygo/tinygo/builder/jobs.go:123 +0x2c fp=0x40181ddfd0 sp=0x40181ddfb0 pc=0x7c045c
runtime.goexit()
        /usr/local/go1.21.0/src/runtime/asm_arm64.s:1197 +0x4 fp=0x40181ddfd0 sp=0x40181ddfd0 pc=0x4e6994
created by github.com/tinygo-org/tinygo/builder.runJobs in goroutine 1
        /home/ayke/src/tinygo/tinygo/builder/jobs.go:123 +0x434

[aykevl]

This is actually a rather interesting bug. We insert a special call that is later removed again to get the maximum stack size of a function (if it can be calculated). Originally it looks like this:

getGoroutineStackSize(door)
...
getGoroutineStackSize(elevatorYO)

...but LLVM thinks it is smart and converts it to code equivalent to this:

fn := someCondition ? door : elevatorYO
getGoroutineStackSize(fn)

This later pass that transforms the getGoroutineStackSize call chokes on this transformation: it still assumes the function parameter is a function, not a variable containing a reference to a function.

Normally a transformation like this would be a good idea, but in this case it actually makes writing the pass more difficult.

I'll have to think a bit on how to correctly fix this bug.

[aykevl]

I think a fix would be a rewrite of the getGoroutineStackSize pseudo-call and convert it to actual loads from external globals (that later get merged into one big global). I don't see how the optimizer could mess that up. It's a bit involved though.