Debugger Support?

[waj334]

What should I expect for debugger support? I'm able to get Atmel Studio to load a .o file and attach to my Adafruit Feather M0 over JLink, but with no support breakpoints (except in assembly) or local variables. From my understanding, this is just as good as GDB is going to get with debugging Go and Delve is the way to go (no pun intended). What would be needed to possibly get Delve working?

[aykevl]

Have you tried tinygo gdb? It may need some configuring, for example with -programmer=jlink.

Debug information support is not complete but close to what you would get with C. That means local variable are sometimes visible and sometimes optimized away. And it works with GDB, not Delve (I haven't tried Delve and I don't think it'll work).

Why .o? That's an object file, you'll probably need a linked ELF binary.

[waj334]

Have you tried tinygo gdb? It may need some configuring, for example with -programmer=jlink.

I haven't tried it yet because I use modules and I had trouble building the dev branch on Windows.

Debug information support is not complete but close to what you would get with C. That means local variable are sometimes visible and sometimes optimized away. And it works with GDB, not Delve (I haven't tried Delve and I don't think it'll work).

Why .o? That's an object file, you'll probably need a linked ELF binary.

No reason except that was the file type that the IDE accepted and it worked. But it seems it can load up .ELF files too

Will at least breakpoints work when using the tinygo gdb command?

[waj334]

Found a way to test out the gdb functionality and code breakpoints do work from the terminal. I'm still learning my new debugging tools so please forgive my noobiness. Would turning off some of the optimizations allow me to see variable values?

[aykevl]

Glad you got GDB to work!

Would turning off some of the optimizations allow me to see variable values?

Maybe. You can try -opt=1 which may make debugging a bit easier, at the cost of binary size. There is also -opt=0 but I think it's currently broken.
Sometimes when a variable is not available in the current stack frame, you can look in other places (for example, it may be available in the parent stack frame). Or, if needed, use println to print a value (which may also make it available in the debugger as a side effect).

[waj334]

Setting opt=1 seemed to help a little. I can see all of the local variables and their data type size, but it seems that my debugger does not know where to look in memory for their actual values.

[aykevl]

I think there are a few bugs around composite types (structs, strings, slices, ...), which may make debugging harder.

Additionally, some Go types in particular are presented to the debugger as structs. For example, strings are translated to a struct containing a pointer and a length. You may need to print the individual fields to get their value.

If you give a screenshot of a debugging session I might be able to suggest a way to print particular values.

[jbpratt]

I think this can be closed, doesn't seem there is anything actionable.

[deadprogram]

Closing, please reopen if needed.