GDB

[Graham King]

Hi,

When a go-routine returns from a syscall (or hits any scheduling point), it can continue execution on a different OS thread. If I'm stepping through the code in GDB, is there any way for GDB to know which thread the next instruction of my go-routine will execute on?

Right now it looks like Go stays on the current OS thread, so it loses the go-routine (http://code.google.com/p/go/issues/detail?id=7369). It seems GDB follows OS threads, when we want to follow go-routines.

Is GDB support for Go possible? Wouldn't it require some communication between Go's scheduler and GDB?

Many thanks,
Graham

[Russ Cox]

On Mon, Mar 3, 2014 at 11:21 AM, Graham King <gra...@gkgk.org> wrote:

Hi,

When a go-routine returns from a syscall (or hits any scheduling point), it can continue execution on a different OS thread. If I'm stepping through the code in GDB, is there any way for GDB to know which thread the next instruction of my go-routine will execute on?

Not that I'm aware of. You could set a breakpoint where it will continue.

 

Right now it looks like Go stays on the current OS thread, so it loses the go-routine (http://code.google.com/p/go/issues/detail?id=7369). It seems GDB follows OS threads, when we want to follow go-routines.

Is GDB support for Go possible? Wouldn't it require some communication between Go's scheduler and GDB?

Actually I think we're moving in the other direction. Give up on making gdb smart and do something better, not that we know what that is yet. The only thing I'm willing to guarantee will stay in gdb support for the long term is support for stack traces and pc/line mappings. 

Russ

[Florin Patan]

Hi Russ,

In regards to the last statement.

I've just spent a bunch of time integrating gdb into an IDE so we can support it as it's one very popular feature requests (and not only for the platform that I'm working on). My very biased view is that a (good) debugger is an incredible powerful tool to have in the toolbox and gdb is already a very good tool.

The subject of porting the current go compiler from C to go has a very interesting point that it's better to write a C to go translator rather than lose ten years of man work.

As such my question is: do you really think it's worth investing the time to create a new tool that can be used only with go programs when you already have one that can be used with existing apps, people are used to it and has all the features gdb has?

Unfortunately my C skill is a bit nonexistent to be able to pick a task such as improving gdb itself but I will try to make time and help the efforts. The thing is that I don't want to spend time on an issue then, someone have a: yeah, we don't support it anymore, we do it our way(tm) moment.

Kind regards,

Florin

[Russ Cox]

On Mon, Mar 3, 2014 at 5:47 PM, Florin Patan <flori...@gmail.com> wrote:

Actually I think we're moving in the other direction. Give up on making gdb smart and do something better, not that we know what that is yet. The only thing I'm willing to guarantee will stay in gdb support for the long term is support for stack traces and pc/line mappings. 

 

In regards to the last statement.

I've just spent a bunch of time integrating gdb into an IDE so we can support it as it's one very popular feature requests (and not only for the platform that I'm working on). My very biased view is that a (good) debugger is an incredible powerful tool to have in the toolbox and gdb is already a very good tool.

The subject of porting the current go compiler from C to go has a very interesting point that it's better to write a C to go translator rather than lose ten years of man work.

As such my question is: do you really think it's worth investing the time to create a new tool that can be used only with go programs when you already have one that can be used with existing apps, people are used to it and has all the features gdb has?

The basics will continue working: stack traces, pc-line number mappings, and therefore breakpoints and so on. But we're failing badly at teaching gdb enough to understand concepts like goroutines. The only solution is to work on gdb itself - the Python API is not enough - and that doesn't help with lldb at all.

If we can do something different that actually supports Go well, we'll do that. We haven't yet, and we've been talking about it since 2008. But it might be a better use of time than chasing corner case after corner case in the gdb support.

Like I said, we'll definitely keep enough information to keep stack traces, breakpoints, and so on working. The rest I'm not so sure about.

Russ

[Aram Hăvărneanu]

Shameless advertising -- the Joyent folks added support for Go to mdb,
the Solaris debugger, you can read some more about it here:
http://www.joyent.com/blog/mdb-support-for-go

I've found it very helpful in debugging the port, much helpful than
gdb (if I have to use gdb I just disable the extension).

--
Aram Hăvărneanu

[minux]

i think gdb on the smartos builder is broken, it can even run a C program.

[Aram Hăvărneanu]

> i think gdb on the smartos builder is broken, it can even run a C program.

Seems to work just fine, just tested it, although do learn mdb, it
will save you pain. Mdb is useful even for analysing Linux core dumps.

--
Aram Hăvărneanu