How to debug Go programs using GoClipse?

Question

Am using Go (go1.3 darwin/amd6) and GoClipse 0.8 on OS X Mavericks...

Was having trouble running the Debugger (after setting breakpoints) so I scoured Stack Overflow and also the rest of the Internet and discovered that I needed to install gdb.

Followed the following instructions (to a T) (by installing gdb via HomeBrew):

http://ntraft.com/installing-gdb-on-os-x-mavericks/

Now, when I place a breakpoint and Run my go program through Eclipse's debugger, it steps through assembly code instead of Go code:

e.g.

A breakpoint was set that this line inside my go program:

responses := [] *HttpResponse{}

When I ran the debugger, it opened up a file called:

rt0_darwin_amd64.s

and the line of code that it was set on was:

MOVQ    $_rt0_go(SB), AX

And when I tried to "Step Over" my code, it kept doing so through these assembly files...

I don't know assembly (and don't think I have the time to learn it)... Is there a simple way of debugging Go program using the Eclipse debugger?

Answer 1

What does the Debug view display when your Go program stops? (The Debug view is what shows your stack trace). Does it display a stack trace similar to this:

Thread [1] 0 (Suspended : Breakpoint)   
    main() at rt0_windows_amd64.s:15 0x42a400   
    KERNEL32!BaseThreadInitThunk() at 0x773259ed    
    0x0 

(note: for OSX, it would be main() at rt0_darwin_amd64.s)

If so, here is what is happening: When you started the program, it stopped automatically on the "main" function on program startup. But that's not the Go main, but rather an internal runtime "main" function, whose code is written in C, (and for which there is no source available, that's why you see the assembler). This is controlled by the first option in the the launch configuration options, as you can see here:

You can change it to "main.main" to stop on the actual Go main, or just unchecked it. In any case, if the debugger stops there, you can just click Run / Resume (F8) to continue.

Answer 2

I think that what is happening is that the debug information are being stripped from the binary.

Make sure that when compiling the binary in debug mode that you add the flags -gcflags "-N -l" documented in http://golang.org/doc/gdb

The code generated by the gc compiler includes inlining of function invocations and registerization of variables. These optimizations can sometimes make debugging with gdb harder. To disable them when debugging, pass the flags -gcflags "-N -l" to the go command used to build the code being debugged.