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