[go-nuts] The state of gdb support

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