【问题标题】:symbols not showing up when debugging under clang 3.3/3.4 vs gcc 4.8在 clang 3.3/3.4 vs gcc 4.8 下调试时符号不显示
【发布时间】:2014-01-29 22:29:05
【问题描述】:

情况:

我有一个用 c++11 编写的 autotools 项目,我可以使用 clang 3.3/3.4 或 gcc 4.8 进行编译。 我的 autotools 项目构建了一个共享库和一个可执行文件。

如果我使用 gcc 4.8 并调试可执行文件,我可以添加一个观察点来检查共享库中存在的全局变量的值。

当我使用 QT creator 或 CDT 或其他调试器时,甚至当我查看 gdb 7.6.2 的输出时:使用 clang 编译时,它在调试输出中显示“没有这样的值”,而使用 gcc 我可以在调试器中检查全局变量的值。

我将基本相同的开关发送到 gcc 和 clang,-O0 -g。使用这两个编译器,我可以检查并查看堆栈上的值,但仅使用 clang 3.3 或 clang 3.4 生成的输出我无法检查共享库中存在的全局变量。我的环境是Ubuntu 12.04,自带clang和gdb。

我已确认我正在检查的全局符号确实存在于任一编译器生成的共享库中。

是否有一些特定的编译器开关或我应该发送给 clang 以便能够调试共享库中的符号的东西?或者这可能是一个clang的错误?

【问题讨论】:

  • 您是否尝试列出 GDB 中的可用符号(我假设您应该提及调试器)?例如,可能会发生一些名称修改。另一件事是让编译器输出特定于目标的汇编代码并查看它在那里的名称(在 GCC 中它是 gcc -S, IIRC)。

标签: c++ clang


【解决方案1】:

根据我的经验,clang 3.3 会弄乱调试信息。让我们以一个简单的程序为例:

#include <string>

int main()
{
  std::string s("foo");
  s.size();

  return 0;
}

编译:

$ clang++ -O0 -ggdb -c t.cpp -o t.o

现在让我们检查调试符号:

$ objdump --dwarf=info t.o | grep -A2 -B1 _Rep
 <3><3c3>: Abbrev Number: 29 (DW_TAG_structure_type)
    <3c4>   DW_AT_name        : (indirect string, offset: 0x2ff): _Rep
    <3c8>   DW_AT_declaration : 1
 <3><3c8>: Abbrev Number: 28 (DW_TAG_subprogram)

如您所见,_Rep(它是 std::string 的一部分)用 DW_AT_declaration 属性标记,这意味着 _Rep 已声明,但未定义。这就是为什么在使用 gdb 进行调试时,如果您对上面的程序尝试 print s,您会看到 No type named std::basic_string&lt;char&gt;::_Rep

_Rep 的调试信息实际上必须是这样的:

$ objdump --dwarf=info t.o | grep -P -A4 -B1 '\b_Rep\b'
 <3><119>: Abbrev Number: 16 (DW_TAG_structure_type)
    <11a>   DW_AT_name        : (indirect string, offset: 0x578): _Rep
    <11e>   DW_AT_byte_size   : 24
    <11f>   DW_AT_decl_file   : 7
    <120>   DW_AT_decl_line   : 155
 <4><121>: Abbrev Number: 11 (DW_TAG_inheritance)

我敢打赌,你的 clang 遇到过这种或类似的情况。

【讨论】:

    猜你喜欢
    • 2011-08-30
    • 2016-01-29
    • 2021-11-20
    • 2014-05-20
    • 2013-08-06
    • 1970-01-01
    • 2014-09-08
    • 2014-04-24
    • 1970-01-01
    相关资源
    最近更新 更多