Fwd: The state of gdb support

[Rob Pike]

Sending to golang-dev, where I meant to in the first place. Please
focus your conversation here.


---------- Forwarded message ----------
From: Rob Pike <r...@golang.org>
Date: Wed, Mar 5, 2014 at 3:42 PM
Subject: The state of gdb support
To: "golan...@googlegroups.com" <golan...@googlegroups.com>


I have added a label "GDB" to the issue tracker and attached it to the
gdb issues I could find. If more arise, please use the label.

While on the topic, I want to be clear that gdb support for Go is poor
and unlikely to improve significantly. There is a little bit of Go
support and it sometimes works and is sometimes useful, but gdb does
not understand how the Go runtime works and likely never will. For
example, the mapping of goroutines to threads changes while the
program is running, which can defeat breakpointing completely.

When gdb works, it is handy, but it is often absent (Windows, Darwin)
and often broken (see all the issues I just tagged). Moreover, there
is no one on the Go team, or elsewhere for that matter, committed to
making the support reliable and solid, even for the platforms where it
does exist. And even if such a person existed, some of the fundamental
issues could probably never be resolved.

I hope a better solution to debugging Go programs arises at some
point, but it's clear that gdb is not the right avenue to pursue to
reach that goal.

It's therefore worth making the situation clear by reiterating what
was said earlier this week about the state of gdb support for Go:

Although we will endeavor to keep basic gdb functionality (stack
traces, printing values) working on supported platforms, the ability
to use the debugger to understand a Go program's full environment will
likely never work, and improving gdb support is not a priority for the
team.

-rob

[Rob Pike]

Minux: you are right that the documentation needs to address this
point, and there are issues filed for updating the docs.

-rob

[Rob Pike]

It's really not clear what the right long-term solution is. What is
clear is that gdb is not it.

-rob

[minux]

On Wed, Mar 5, 2014 at 12:17 AM, Rob Pike <r...@golang.org> wrote:

Minux: you are right that the documentation needs to address this
point, and there are issues filed for updating the docs.

I've gone through all label:GDB issues, and didn't find any that covers this,

so i filed https://code.google.com/p/go/issues/detail?id=7471. 

[minux]

I realized that the issue tracker is not for discussion, so i copied the content

of issue 7471 below for discussion:

Issue 7471: doc/gdb: document the plan for future gdb support

What we need to say:

1. gdb might not work as expected.

2. we can't make it correct, we're still trying to find other ways.

(i think the reason is that:

a) correct goroutine handing is beyond the scope of Python interface, and python support doesn't benefit lldb;

b) even if we can implement the goroutine handling in gdb proper, there is still problem of version skew

problem (people using out-dated version of gdb to debug new version of Go). also, the release schedule

of go and gdb are different, as long as we don't fork gdb and include gdb in the binary releases, the

gdb support won't ever be perfect.)

If we fork gdb, then we may as well develop our own solution. Is my reasoning correct here?