Re: Golang debugging issues

Re: Golang debugging issues

[Jan Kratochvil]

Hello Derek,

> My name is Derek and I’ve been working on Delve. I got a link to
> https://sourceware.org/gdb/wiki/GoDebugging

I am maintaining that page.


> Delve is pre 1.0 and under heavy, active development, with some
> pretty big improvements making their way into master soon. I’d
> really like to hear your thoughts regarding shortcomings of current
> debuggers with regard to Go.

The problem with debugging Go is its incorrect+incomplete DWARF.  That needs
to be fixed in golang, I do not see anything missing in GDB if golang has been
producing debug info correctly.

gccgo produces more correct DWARF - or at least the missing parts would be
easier to fix than the incorrect+missing parts from golang - but for some
reason developers in Go language insist on using golang.  I heard golang
produces more effective real world binaries (despite synthetic benchmarks
I have seen performed better in gccgo) because of better variable escape
optimizations - common with all the variable bindings in Go functions.

The language of the debugger is unrelated to the language it is debugging.
We can discuss whether GDB is the right debugger in general but then there is
also LLDB to consider.

So I am curious what features should Delve provide which GDB does not.
And if there are any why it isn't easier to script them in Python for GDB
instead of writing a new debugger from scratch.


Regards,
Jan

Re: Golang debugging issues

[Jan Kratochvil]

Hello Derek,

On Fri, 27 Mar 2015 18:56:07 +0100, Derek Parker wrote:
> A fundamental issue, I think, is handling Go’s concurrency model. Where
> every language gdb / lldb can debug could be multithreaded, the model is
> different. In particular, a lack of knowledge of Go’s runtime scheduler can
> be an issue. Goroutine tracking across thread switches, handling not only
> the kernel scheduler but the Go runtime scheduler. When you have highly
> parallel programs running a lot of concurrent goroutines, a debugger that
> has no knowledge of the specific concurrency model could thrash about,
> especially since a large amount of goroutines can be created running the
> same routine, trying to `next` over a source line can land you back in the
> same spot on a separate goroutine.
> 
> Could these issues be solved with Python scripts? Potentially, however that
> approach could likely fall short. I know the core Go team has worked on some
> Python scripts, however mostly pretty printers, etc..

I agree.  GDB Python scripting is not enough here, GDB would need to be
extended by a new threads kind and/or overload the current one.

Listing running goroutines and/or running single GDB command in the context of
each goroutine is already supported by GDB runtime-gdb.py ("info goroutines",
"goroutine").  Still that would be insufficient for the commands like 'next'.
Just I find these golang issues
	https://sourceware.org/gdb/wiki/GoDebugging#golang_Wrong_DW_TAG_variable
	https://sourceware.org/gdb/wiki/GoDebugging#golang_Missing_CFI
somehow blocking the usefulness of the 'next' command.

Thanks for the insight into Delve development.


Jan