Revisting 1157 - Adding delve support for TinyGo

mytechnotalent commented 2 years ago

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:

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

Thank you!

dkegel-fastly commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

On a less related note...

I am trying to support gdb in my VSCode plugin. https://github.com/tinygo-org/vscode-tinygo/pull/4

mytechnotalent commented 2 years ago

@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 commented 2 years ago

is this possible>?

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

try r (for run) to start a process?

mytechnotalent commented 2 years ago

@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 commented 2 years ago

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

mytechnotalent commented 2 years ago

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

mytechnotalent commented 2 years ago

@aykevl

aykevl commented 2 years ago

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 commented 2 years ago

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

mytechnotalent commented 2 years ago

@aykevl I will Google to see what programmer I need to buy for the Pico. I am not certain. I have a ST-LINKv2 but obviously would only work with STM ARM chips.

aykevl commented 2 years ago

I have a ST-LINKv2 but obviously would only work with STM ARM chips.

No, it works with most chips that support SWD (that's most Cortex-M chips). It will likely work with the RP2040 but I didn't test it. I found it a bit unreliable though. I have had good experience with DAPLink based debuggers, in particular the Particle Debugger (that's sadly discontinued). But any DAPLink based debuggers should work. You can even program some other boards as a debugger, there are some tutorials about it (but sadly it seems like you can't use another RP2040 to debug a RP2040).

soypat commented 2 years ago

@mytechnotalent I managed to get debugging up and running with the pi pico using another pi pico with the picoprobe firmware loaded in. Never tried running it on VSCode but gdb on its own worked perfectly fine. Could peek at registers and whatnot.

soypat commented 2 years ago

I believe @ysoldak managed to get VSCode debugging working with the pico if I'm not mistaken.

ysoldak commented 2 years ago

Yes, I was able to debug RP2040 with pyOCD and using another RP2040 board as debugger. Mind TinyGo does not support pyOCD yet, so I had to hack a bit: https://github.com/tinygo-org/tinygo/pull/2632

tinygo-org / tinygo

Revisting 1157 - Adding delve support for TinyGo #2888