Question

g ++（GCC）5.2.0

clang version 3.7.1（tags / RELEASE_371 / final）

GNU gdb（GDB）7.12

由于某种原因，在使用clang编译时，Gdb无法找到std :: string的定义。我有自定义编译和构建gcc和clang，因为Centos 6.5附带了旧版本的gcc。

示例代码

#include <string>

int main()
{
    std::string s("This is a string");

    return 0;
}

使用g ++编译和调试 - 工作得很好

[~]$ g++ -ggdb3 -std=c++14 stl.cpp 
[~]$ gdb a.out
GNU gdb (GDB) 7.12
Reading symbols from a.out...done.
(gdb) break main
Breakpoint 1 at 0x400841: file stl.cpp, line 5.
(gdb) r
Starting program: /home/vagrant/a.out 

Breakpoint 1, main () at stl.cpp:5
5       std::string s("This is a string");
(gdb) n
7       return 0;
(gdb) p s
$1 = {static npos = <optimized out>, 
  _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x612c20 "This is a string"}, _M_string_length = 16, {
    _M_local_buf = "\020\000\000\000\000\000\000\000\300\b@\000\000\000\000", _M_allocated_capacity = 16}}
(gdb)

检查它是否与我的rpm构建版本的libstdc ++链接而不是系统

[~]$ ldd a.out
    linux-vdso.so.1 =>  (0x00007ffd709e0000)
    libstdc++.so.6 => /opt/spotx-gcc/lib64/libstdc++.so.6 (0x00007f29318fa000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f2931676000)
    libgcc_s.so.1 => /opt/spotx-gcc/lib64/libgcc_s.so.1 (0x00007f293145f000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f29310cb000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2931c93000)

[~]$ objdump -T -C a.out
a.out:     file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
0000000000000000  w   D  *UND*  0000000000000000              _Jv_RegisterClasses
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __libc_start_main
0000000000000000  w   D  *UND*  0000000000000000              _ITM_deregisterTMCloneTable
0000000000000000  w   D  *UND*  0000000000000000              _ITM_registerTMCloneTable
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.21 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4 std::allocator<char>::~allocator()
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.21 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4 std::allocator<char>::allocator()
0000000000000000      DF *UND*  0000000000000000  GCC_3.0     _Unwind_Resume
0000000000400700      DF *UND*  0000000000000000  CXXABI_1.3  __gxx_personality_v0

如果我用clang

尝试相同的话，现在看起来都很好

[~]$ clang++ -std=c++14 -g stl.cpp
[~]$ gdb a.out
GNU gdb (GDB) 7.12
Reading symbols from a.out...done.
(gdb) break  main
Breakpoint 1 at 0x400853: file stl.cpp, line 5.
(gdb) r
Starting program: /home/vagrant/a.out 

Breakpoint 1, main () at stl.cpp:5
5       std::string s("This is a string");
(gdb) n
7       return 0;
(gdb) p s
$1 = <incomplete type>
(gdb)

现在我得到一个不完整的类型 - 但正在使用相同的库

[~]$ ldd a.out
    linux-vdso.so.1 =>  (0x00007fff5352d000)
    libstdc++.so.6 => /opt/spotx-gcc/lib64/libstdc++.so.6 (0x00007f76b4023000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f76b3d9f000)
    libgcc_s.so.1 => /opt/spotx-gcc/lib64/libgcc_s.so.1 (0x00007f76b3b88000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f76b37f4000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f76b43bc000)


[~]$ objdump -T -C a.out
a.out:     file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000000  w   D  *UND*  0000000000000000              __gmon_start__
0000000000000000  w   D  *UND*  0000000000000000              _Jv_RegisterClasses
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 __libc_start_main
0000000000000000  w   D  *UND*  0000000000000000              _ITM_deregisterTMCloneTable
0000000000000000  w   D  *UND*  0000000000000000              _ITM_registerTMCloneTable
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.21 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4 std::allocator<char>::~allocator()
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.21 std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4 std::allocator<char>::allocator()
0000000000000000      DF *UND*  0000000000000000  GCC_3.0     _Unwind_Resume
0000000000400700      DF *UND*  0000000000000000  CXXABI_1.3  __gxx_personality_v0

有没有人对我去过的地方或我错过的东西有任何建议。两个编译器在构建它们时都是自举的 - 一切看起来都很好 - 它似乎是std :: string在使用clang时没有定义。

Answer 1

正如ks1322所提到的，这是因为clang决定不为libstc ++发出调试信息。

您可以通过提供以下标志强制clang： -D_GLIBCXX_DEBUG

我只提供调试版本的标志，但如果调试是默认版本，而版本版本是特殊目标，则应删除它：

release: CXXFLAGS := $(filter-out -D_GLIBCXX_DEBUG,$(CXXFLAGS)) -O2

这为我解决了同样的问题。

Answer 2

我在Fedora上用系统clang重现了这个问题。

看来clang没有为std::string发出调试信息，因为它被告知libstdc++提供了它。请参阅bug 24202的评论：

看起来您没有安装libstdc ++的调试信息：


缺少单独的debuginfos，请使用：dnf debuginfo-install libgcc-5.1.1-4.fc22.x86_64 libstdc ++ - 5.1.1-4.fc22.x86_64


Clang没有为std :: string发出调试信息，因为它是   告诉libstdc ++提供它（但在你的情况下，它不是   安装）;这是GCC显然的调试大小优化   没有表现。

如果安装libstdc ++的调试信息，这是否有效？

我已使用命令libstdc++为dnf debuginfo-install libstdc++-6.2.1-2.fc25.x86_64安装了调试信息，并解决了该问题。

Answer 3

clang 相信可以使用 libstd++ 的调试符号，因此您必须安装它们。有关如何在 Fedora 上执行此操作的信息，请参阅 ks1322 的答案。在 Ubuntu 上，运行：

sudo apt-get install libstdc++6-dbgsym

在那之后，一切都会好起来的。

不要定义_GLIBCXX_DEBUG，因为这会破坏libstdc++的abi。

-fno-limit-debug-info 将使 clang 发出比必要更大的调试信息，所以我也建议不要这样做。只需安装 libstdc++ 的调试信息包。

Answer 4

bug 24202 as linked by ks1322中提到的最后一种解决方法值得一看：

-fno-limit-debug-info将使您的调试信息更大，速度较慢的链接（如果您未使用-gsplit-dwarf）和调试器性能。但是，是的，将解决此问题。

使用-fnolimit-info会强制Clang发出调试信息，例如std :: string以较大的二进制文件为代价，同时保持与其他库和系统/ SDK其余部分的兼容性。

正如ks1322和Kevin所提到的，可以改为使用-D_GLIBCXX_DEBUG将libstdc ++切换到debug mode，但这付出了沉重的代价：与之链接并与之交换STL容器（字符串，向量等），也必须使用-D_GLIBCXX_DEBUG构建。意思是：您的系统/ SDK必须通过一组单独的库来支持此功能，否则您将不得不自行重建它们。

使用clang

4 个答案: