【问题标题】:GDB: running cpp process debugging without symbolsGDB:运行无符号的cpp进程调试
【发布时间】:2018-08-25 05:25:07
【问题描述】:

运行应用程序的 Linux 系统。此应用程序是一个没有任何调试符号的 cpp 二进制文件。一些如何使用 100% cpu 的应用程序。想调试它为什么无限运行。如果我停止并用调试符号替换二进制文件,问题可能无法重现。

因此,在另一个环境中运行带有调试符号的相同应用程序。这里运行良好。

我可以比较它们(有和没有调试符号二进制文件)并推断使用 GDB 的问题吗?

【问题讨论】:

  • 分析器可能会帮助您缩小问题站点的范围。您可能不会获得函数名称,但您应该获得一个地址,如果您将链接器配置为提供一个内存映射,您可以使用内存映射返回问题函数。
  • 太棒了。你能用一些例子解释更多细节吗?
  • 调试符号不需要内置到正在运行的二进制文件中进行调试,您只需将带有调试符号的二进制文件加载到gcc中
  • @AlanBirtles,您能提供更多详细信息吗?

标签: c++ debugging gdb


【解决方案1】:

此应用程序是一个没有任何调试符号的 cpp 二进制文件

不需要任何调试符号来了解它在哪里花费时间,您只需要应用程序不被完全剥离(大多数二进制文件不是)。

使用perf record -p $pid收集CPU配置文件,然后perf report进行分析。

如果应用程序完全剥离,您仍然可以使用perf record 收集程序计数器值,然后perf record --symfs ... 将其指向应用程序的未剥离副本。文档here

注意:剥离和未剥离的副本都必须使用完全相同相同的构建标志构建,否则您会得到垃圾。最佳做法是始终将未剥离的副本保存为构建过程的一部分。

【讨论】:

  • 但应用环境受限于获取性能报告。仅使用 GDB 解决此问题的任何其他方法。
  • @Kranthi 以什么方式受到限制?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2014-07-19
  • 1970-01-01
  • 1970-01-01
  • 2013-04-16
  • 1970-01-01
  • 2015-06-13
  • 1970-01-01
相关资源
最近更新 更多