英文:
How to debug Go programs using GoClipse?
问题
我正在使用Go（go1.3 darwin/amd6）和GoClipse 0.8在OS X Mavericks上...
在设置断点后，我遇到了运行调试器的问题，所以我在Stack Overflow和其他互联网资源上搜索，发现我需要安装gdb。
按照以下说明（通过HomeBrew安装gdb）进行操作：
http://ntraft.com/installing-gdb-on-os-x-mavericks/
现在，当我在Eclipse的调试器中设置断点并运行我的Go程序时，它会跳转到汇编代码而不是Go代码：
例如，
在我的Go程序中设置了一个断点：
responses := []*HttpResponse{}
当我运行调试器时，它打开了一个名为：
rt0_darwin_amd64.s
并且设置的代码行是：
MOVQ $_rt0_go(SB), AX
当我尝试“Step Over”我的代码时，它继续通过这些汇编文件进行跳转...
我不懂汇编语言（也没有时间学习它）... 有没有一种简单的方法可以使用Eclipse调试器调试Go程序？
英文:
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?
答案1
得分: 5
当你的Go程序停止时，调试视图会显示什么？（调试视图显示堆栈跟踪）。它是否显示类似于以下内容的堆栈跟踪：
线程 [1] 0（暂停：断点）
main() at rt0_windows_amd64.s:15 0x42a400
KERNEL32！BaseThreadInitThunk() at 0x773259ed
0x0
（注意：对于OSX，它将是main() at rt0_darwin_amd64.s）
如果是这样的话，这是发生的情况：当你启动程序时，它会自动停在程序启动时的“main”函数上。但这不是Go的主函数，而是一个内部运行时的“main”函数，其代码是用C编写的（并且没有可用的源代码，这就是为什么你看到汇编代码）。
这由启动配置选项中的第一个选项控制，如下所示：
你可以将它更改为“main.main”以停在实际的Go主函数上，或者只是取消选中它。无论如何，如果调试器停在那里，你可以点击“运行/继续”（F8）来继续执行。
英文:
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.
答案2
得分: 1
我认为正在发生的情况是二进制文件中的调试信息被剥离了。
在以调试模式编译二进制文件时，请确保添加文档中所述的-gcflags "-N -l"标志。
gc编译器生成的代码包括函数内联和变量寄存器化。这些优化有时会使使用gdb进行调试更加困难。要在调试时禁用它们，请将
-gcflags "-N -l"标志传递给用于构建正在调试的代码的go命令。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论