我发现自己处于几乎没有任何调试工具的情况下不得不调试 Qt 应用程序的困难境地:应用程序似乎开始使用越来越多的 CPU，因为它一次又一次地运行相同的操作；许多小时后 CPU 完全饱和。
该应用程序在 ARM Linux 嵌入式设备上运行，其中 gdb 似乎无法工作，可能很难通过提供的工具链发现问题。 strace 似乎只报告计时器事件(这是一个 OpenGL 应用程序，所以这是预期的)。 ltrace 不可用，编译它导致了一项艰巨的任务，也许毫无用处。我没有编写应用程序，但源代码可用。
我还能做些什么来发现应用程序在消耗那么多资源时忙于做什么吗？我必须以任何方式跟踪应用程序执行的所有方法调用吗？我可以使用任何其他技术来尝试猜测问题或将注意力集中在何处吗？
编辑:这是 gdb 的问题之一:Only question marks in backtrace reported by gdb on ARM .即使编写一个十行的应用程序来模拟段错误也会导致这种情况。
最佳答案
你能在机器上启用核心转储吗？然后当它运行时，您可以向它发送一个 SIGABRT 并将核心转储复制到您的开发机器，并使用交叉调试器检查它，并提供源代码和未剥离的可执行文件。
下次吸取惨痛的教训也很重要，不要使用支持如此糟糕的工具链。
如果它是一个选项，如果不支持 gdb，您可以尝试另一个至少具有 gdbserver 的工具链。我对 CodeSourcery ARM Lite 工具链非常满意。
编辑:适合您情况的 gdb 有两种形式:
- 在您的开发主机上运行的交叉 gdb
- 在您的目标上运行的 native gdb
gdbserver 允许您在开发主机上运行 cross-gdb 并连接到目标以远程调试在其上运行的东西。因此，核心转储或 gdbserver 是使用交叉 gdb 检查目标上的某些内容的两种方法，但单独使用 gdbserver 对你帮助不大。
如果您的交叉编译器类似于 arm-none-linux-gnueabi-gcc，请查看您是否有可用的 arm-none-linux-gnueabi-gdb在您的开发主机上。
关于c++ - 不用调试工具的调试技巧，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9800239/