Revisting 1157 - Adding delve support for TinyGo

[mytechnotalent]

I wanted to extend the closed topic 1157 and first inquire to @deadprogram or the team is it possible to use delve with TinyGo? I know we have gdb which is ok but working with delve would really scale the growth of ease-of-use debugging.

The purpose of this issue is to:

1. is this possible>?
2. if 1 is true, what would be the level of effort to design this?

Thank you!

[dkegel-fastly]

We have more than gdb; we have lldb as well, and possibly many other native debuggers.

I suspect dlv is tightly coupled to upstream go, and would be hard to support.

Maybe we should add a dlv-to-native-debugger cheat sheet in the doc to help people get used to native debugging?

[mytechnotalent]

@dkegel-fastly it would be great to have a dlv as it would be just one less step for Go Developers to get on the TinyGo adoption train however in the meantime a dlv-to-native-debugger cheat sheet integrated into the documentation is a great idea in my opinion.

[sago35]

On a less related note...

I am trying to support gdb in my VSCode plugin.
tinygo-org/vscode-tinygo#4

[mytechnotalent]

@sago35 this is fantastic! If you get traction on this can you write up a detailed step-by-step tutorial so people can adopt it quickly? Most are using VSCode so would be ideal!

[aykevl]

1. is this possible>?
2. if 1 is true, what would be the level of effort to design this?

I honestly don't know. I don't know how deeply Delve is coupled with details of upstream Go. I also have never used Delve (I guess I should, I just never have so far) so I don't know how it works. But here are some facts of interest:

• TinyGo uses a different calling convention. Basically the C calling convention with some small changes. This information is of course encoded in DWARF debug information (for gdb/lldb).
• A few data structures are different. Some basic types like strings, slices, floats, etc are the same but more complex stuff like func, map, interface, etc is different. For example, the func type is implemented as two pointers whereas upstream Go uses a single pointer.
• Goroutines are somewhat different. We currently don't support parallelism. Switching between goroutines is done in assembly. Each goroutine has a fixed-size stack (that can't grow).
• The GC is conservative, there is (currently) no GC type information at runtime.
• The runtime doesn't keep track of existing goroutines. Goroutine stacks are garbage collected like any other data structure. (A nice side effect of this is that in theory deadlocked goroutines can be garbage collected but I never verified whether this happens in practice).
• Interface method calls are implemented in a very special way, essentially by converting them to a switch over all possible concrete types. The underlying method may be optimized away if the compiler doesn't see a call to it at compile time.

We use DWARF to encode most of these things but it could most certainly be improved. For example, strings are encoded as a DWARF struct type with name string and two fields: ptr and len. This may not match upstream Go, and if it doesn't then I'm certainly willing to align things with upstream.

[mytechnotalent]

One of the frustrating challenges is I can find no where a tutorial on how to use openocd with TinyGo. There is the GDB example with the micro:bit which does not require it but when trying to debug a Pico I am without a solution. In C there is openocd -f interface/raspberrypi-swd.cfg -f target/rp2040.cfg
however I would have no idea where the raspberrypi-swd.cfg or rp2040.cfg would be.

Where I am at currently:
go mod init tinygo-pico
tinygo build -target=pico -o test.elf
tinygo flash -target=pico
tinygo gdb -target=pico tinygo-pico

In GDB obviously without the proper commands to target which I do not have, and openocd. I am stuck.

[aykevl]

I would recommend first getting this to work locally, without running on a microcontroller. TinyGo can also produce Linux binaries.

Regarding OpenOCD: it is called by TinyGo in the background. You can use the -x flag to see the command.
For debugging boards without an on-board debugger, you can use an external debugger that you can specify with the -programmer flag. Also, you do not need the separate tinygo flash command: tinygo gdb will also program the chip before starting the debug session.

EDIT: did you see this page? https://tinygo.org/docs/guides/debugging/

[mytechnotalent]

@aykevl first thank you. Very helpful.
When I run:

developer@Kevins-MacBook-Air tinygo-pico % tinygo gdb -target=pico tinygo-pico 
GNU gdb (GNU Arm Embedded Toolchain 9-2020-q2-update) 8.3.1.20191211-git
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
--Type <RET> for more, q to quit, c to continue without paging--c
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /var/folders/bf/sd0knffj2r32l60mdqmd6t200000gn/T/tinygo3746089371/main...
(gdb) b main.main
Breakpoint 1 at 0x1000139a
(gdb) 

I have not way of attaching to the running process. Am I missing some command?

[dkegel-fastly]

try r (for run) to start a process?

[mytechnotalent]

@dkegel-fastly

(gdb) r
Don't know how to run.  Try "help target".
(gdb) help target
Connect to a target machine or process.
The first argument is the type or protocol of the target machine.
Remaining arguments are interpreted by the target protocol.  For more
information on the arguments for a particular protocol, type
`help target ' followed by the protocol name.

List of target subcommands:

target core -- Use a core file as a target
target exec -- Use an executable file as a target
target extended-remote -- Use a remote computer via a serial line
target record-btrace -- Collect control-flow trace and provide the execution history
target record-core -- Log program while executing and replay execution from log
target record-full -- Log program while executing and replay execution from log
target remote -- Use a remote computer via a serial line
target tfile -- Use a trace file as a target

Type "help target" followed by target subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) 

[aykevl]

You're already attached, and the chip is paused. Use continue (or c) to continue from where you're at.

[mytechnotalent]

(gdb) c
The program is not being run.
(gdb) 

[mytechnotalent]

@aykevl

[aykevl]

Ah I see now. You're not specifying a programmer/debugger (the -programmer flag). Note that you need a separate hardware debugger to debug the pico. You can't just use an USB cable to connect.

That said, there should have been an error about this but there isn't.

[aykevl]

One example usage is tinygo gdb -target=<board> -programmer=cmsis-dap examples/serial, if you're using a DAPLink.