有没有办法让CGO代码的调试符号链接到Go？

我有一些Cgo代码可以链接到我的Go二进制文件中。我有Cgo运行并构建我的代码和包装。在最近的一些变化之后，我开始在我的C++中获得一个免费的双链接，我尝试在lldb下运行我的二进制文件，它捕获malloc恐慌，但这些符号并不是特别有用。有没有办法让CGO代码的调试符号链接到Go？

在香草C或C++我用-g3获得包括变量名和源丰富的调试符号。这使得使用lldb更加高效。但是，我遇到了一些问题，让这些符号显示在我的二进制文件中。我注意到在回溯中，我的函数显示为main'foo，其中foo是我函数的名称。虽然没有其他调试信息存在，但我得到的仅仅是汇编和内存指针/寄存器的跟踪。

我试图调用go build与CGO_CFLAGS="-g3" CGO_CXXFLAGS="-g3"但二进制仍然没有符号。我也试过在我。去文件中添加-g3到CFLAGS/CXXFLAGS在哪里设置其他标志（import "C"前），但这似乎并没有任何工作。我想不出任何其他方式来将这个调试信息添加到我的二进制文件中 - 是否有一些Go特定的标志或构建序列来启用它？

来源

2017-05-18 Brian Armstrong

你碰巧在达尔文吗？ https://golang.org/issue/6942 – JimB

是的，我是。因此，从阅读本文来看，Go听起来就像是坏了，团队不打算修复它。这是一个耻辱：/ –

这个问题听起来像它应该工作，如果你使用xcode而不是gcc。如果你使用C++，也许它也与swig有关。邮件列表可能是这个问题的更好资源。 – JimB

我不知道的过程中如何去& C++链接的作品。但是，如何在OS X上处理调试信息可能会帮助您找出调试信息丢失的位置。

在OS X上大多数系统中，对于单个源文件编译调试信息进入由它制成的.o文件将。您可以验证您的.o文件得到了在各种方式的调试信息，这里有一个：

lldb -o "image dump sections" Target.o --batch | grep DWARF 
    0x00000300 container  [0x0000000000061538-0x0000000000782c77) rwx 0x00061cb8 0x0072173f 0x00000000 Target.o.__DWARF 
    0x00000009 dwarf-str  [0x0000000000061538-0x00000000004eeabc) rwx 0x00061cb8 0x0048d584 0x02000000 Target.o.__DWARF.__debug_str 
    0x0000000a dwarf-loc  [0x00000000004eeabc-0x00000000004ef493) rwx 0x004ef23c 0x000009d7 0x02000000 Target.o.__DWARF.__debug_loc 
    0x0000000b dwarf-abbrev  [0x00000000004ef493-0x00000000004f09a7) rwx 0x004efc13 0x00001514 0x02000000 Target.o.__DWARF.__debug_abbrev 
    0x0000000c dwarf-info  [0x00000000004f09a7-0x00000000006ea7f1) rwx 0x004f1127 0x001f9e4a 0x02000000 Target.o.__DWARF.__debug_info 
    0x0000000d dwarf-ranges  [0x00000000006ea7f1-0x00000000006ec481) rwx 0x006eaf71 0x00001c90 0x02000000 Target.o.__DWARF.__debug_ranges 
    0x0000000e dwarf-macinfo [0x00000000006ec481-0x00000000006ec482) rwx 0x006ecc01 0x00000001 0x02000000 Target.o.__DWARF.__debug_macinfo 
    0x0000000f apple-names  [0x00000000006ec482-0x000000000071134e) rwx 0x006ecc02 0x00024ecc 0x02000000 Target.o.__DWARF.__apple_names 
    0x00000010 apple-objc  [0x000000000071134e-0x0000000000711372) rwx 0x00711ace 0x00000024 0x02000000 Target.o.__DWARF.__apple_objc 
    0x00000011 apple-namespaces [0x0000000000711372-0x00000000007116d6) rwx 0x00711af2 0x00000364 0x02000000 Target.o.__DWARF.__apple_namespac 
    0x00000012 apple-types  [0x00000000007116d6-0x0000000000748797) rwx 0x00711e56 0x000370c1 0x02000000 Target.o.__DWARF.__apple_types 
    0x00000015 dwarf-line  [0x000000000075d348-0x0000000000782c77) rwx 0x0075dac8 0x0002592f 0x02000000 Target.o.__DWARF.__debug_line

如果你什么也没看到这里，那么编译器不发光时的调试信息...

下一步是具体到达尔文，而不是把调试信息到链路级的输出，调试信息留在.o文件，以及“调试图”被插入到输出图像。这就是调试器如何找回到.o文件的方式。你可以看到在做：

$ nm -ap <YourBinary> | grep OSO

你应该在这里看到你所有的.o文件的列表。如果你不这样做，那么在构建过程中的某个时刻，你的二进制文件将被剥离（至少使用strip -S）。你必须知道什么时候发生了，而不是这样做。还要检查.o文件是否仍然是您从上述命令看到的条目所在的位置。这可能是构建过程的某些部分正在移动它们，调试器再也找不到它们了。

来源

2017-05-19 17:22:11

有没有办法让CGO代码的调试符号链接到Go？

回答

相关问题