【问题标题】:libtool slowing down gdblibtool 减慢 gdb
【发布时间】:2014-04-06 05:18:38
【问题描述】:

我有一个更大的 C++ 程序,其中包含很多要调试的模板。不幸的是,gdb 需要几分钟才能读取这些符号。

http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html 包含许多调试选项。

您会建议哪些选项使 gdb 更快/更可用。

更新:看起来速度变慢是由 libtool 引起的。如果 gdb 通过 libtool --mode execute 启动,它会很慢。如果 gdb 启动 gdb .libs/foo 它是合理的快。任何想法为什么要慢得多?

更新:另一个建议是 -fvisibility=hidden 请参阅http://gcc.gnu.org/wiki/Visibility

【问题讨论】:

  • 我很惊讶 GDB 索引 (sourceware.org/gdb/onlinedocs/gdb/Index-Files.html) 没有被提及?您的第一个调试符号加载将与往常一样慢,但使用save gdb-index 命令和一些objcopy 魔法可以大大加快后续调试符号加载时间。在您的构建中,在生成带有调试符号的二进制文件后,我将以批处理模式运行 GDB 以生成并将所述索引合并到其中,并预先生成一个可快速加载的可调试二进制文件。这尤其值得包含在构建机器上。

标签: c++ gcc gdb libtool


【解决方案1】:

有时使用 -fdebug-types-section 可以使事情变得更快一些。但不能保证。

加载几分钟...我想知道这个可执行文件有多大。如果我很绝望,我可能会尝试只编译带有调试信息的选定模块。或者也许看看它是否是一个 gdb 错误。如果它被拆分为可执行文件和一些共享库,并且某些部分不经常更改,您还可以考虑使用“gdb index”功能(参见手册)来加快这些模块的调试信息的加载。

【讨论】:

  • -fdebug-types-section 没有任何区别。可执行文件大约是。 18MB 未剥离和 3.2MB 剥离。 gdb 版本是 7.7,我会尝试从 git 升级到一个版本,看看是否有所不同
  • 7,7 足够新,您可能不会看到太大的不同。这对我来说听起来不是很大,我很惊讶这需要几分钟。
  • 看起来缓慢是由通过 libtool --mode execute 启动 gdb 引起的。 (见更新)
猜你喜欢
  • 1970-01-01
  • 2011-04-20
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-04-23
  • 2011-10-13
相关资源
最近更新 更多