英文:
LiteIDE GDB with Golang
问题
我安装了LiteIDE和GDB。我在LiteIDE中打开了我的Go项目，并在代码的某个位置添加了一个断点。然后我切换回终端并运行了应该触发断点的项目二进制文件，但什么都没有发生。我做错了什么？
英文:
I installed LiteIDE and GDB. I opened my Go project in LiteIDE and added a breakpoint to some point in the code. Then i switched back to terminal and ran the project binary that was supposed to envoke the breakpoint and nothing happened. What am i doing wrong?
答案1
得分: 1
你必须从集成开发环境（IDE）中实际启动可执行文件，才能使断点起作用。
此外，请记住，对于Go 1.3.x甚至更高版本的1.4（dev），gdb基本上没有意义。
来自https://golang.org/doc/gdb的说明：
> GDB对Go程序的理解有限。堆栈管理、线程和运行时包含的方面与GDB期望的执行模型有足够的差异，以至于它们可能会使调试器混淆，即使程序是使用gccgo编译的。因此，尽管GDB在某些情况下可能有用，但对于Go程序来说，特别是在并发程度较高的情况下，它不是一个可靠的调试器。此外，解决这些问题对于Go项目来说并不是一个优先事项，因为这些问题很难。简而言之，下面的说明只应被视为在GDB正常工作时如何使用它的指南，而不是成功的保证。
>
> 未来可能需要一种更加面向Go的调试架构。
英文:
You have to actually launch the executable from the IDE for breakpoints to mean anything.
Also keep in mind that gdb is mostly meaningless with Go 1.3.x and even more so with 1.4 (dev).
From https://golang.org/doc/gdb:
> GDB does not understand Go programs well. The stack management, threading, and runtime contain aspects that differ enough from the execution model GDB expects that they can confuse the debugger, even when the program is compiled with gccgo. As a consequence, although GDB can be useful in some situations, it is not a reliable debugger for Go programs, particularly heavily concurrent ones. Moreover, it is not a priority for the Go project to address these issues, which are difficult. In short, the instructions below should be taken only as a guide to how to use GDB when it works, not as a guarantee of success.
>
> In time, a more Go-centric debugging architecture may be required.
答案2
得分: 0
我使用这个包 https://github.com/gostart/debug/，到目前为止，这是我找到的最好的解决方案。
希望这对你有帮助。
英文:
I use this package https://github.com/gostart/debug/ and so far it is the best solution that I have found.
Hope this helps.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论