Re: Golang debugging issues

Jan Kratochvil <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
Hello Derek,

On Fri, 27 Mar 2015 18:56:07 +0100, Derek Parker wrote:
> A fundamental issue, I think, is handling Gos concurrency model. Where
> every language gdb / lldb can debug could be multithreaded, the model is
> different. In particular, a lack of knowledge of Gos 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.