FAQ
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

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Minux at Mar 5, 2014 at 4:53 am
    Is there any plan to revive the go/ogle project?

    If we've made this decision, I think we should update
    doc/debugging_with_gdb.html
    to warn people that gdb might not work fully as expected and also explain
    the
    fundamental issue there so that people could understand.
    On Tue, Mar 4, 2014 at 11:42 PM, Rob Pike wrote:

    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
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Pike at Mar 5, 2014 at 5:16 am
    Apologies but I meant to send that to the development list, where the
    conversation should continue.

    -rob

    On Wed, Mar 5, 2014 at 3:53 PM, minux wrote:
    Is there any plan to revive the go/ogle project?

    If we've made this decision, I think we should update
    doc/debugging_with_gdb.html
    to warn people that gdb might not work fully as expected and also explain
    the
    fundamental issue there so that people could understand.
    On Tue, Mar 4, 2014 at 11:42 PM, Rob Pike wrote:

    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
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedMar 5, '14 at 4:43a
activeMar 5, '14 at 5:16a
posts3
users2
websitegolang.org

2 users in discussion

Rob Pike: 2 posts Minux: 1 post

People

Translate

site design / logo © 2022 Grokbase