只有在gdb在ARM上报告的回溯中的问号 [英] Only question marks in backtrace reported by gdb on ARM

问题描述

我正在使用ARM上的gdbserver调试软件，以获得崩溃的回溯。不幸的是，我只收到问号。无处不在，我读到这个问题只是与缺少符号有关，但符号不会从我的图书馆中删除。

I'm trying to debug a software with gdbserver on ARM to get a backtrace of a crash. Unfortunately I get only question marks. Everywhere, I read this problem is simply related to the lack of symbols, but symbols are not stripped from my libraries.

如果我尝试使用file命令加载客户端中的符号我得到：

If I try to use the file command to load the symbols in the client I get:

reading symbols from <path>/libQtWebKit.so.4.7.2...(no debugging symbols found)...done.

然后，当发生崩溃时：

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x4bf38b88 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

我的库是在发布中编译的，但符号实际上在那里。用nm我可以找到那些。为什么只得到问号？这只是因为库是通过优化编译的？

My libraries are compiled in release but the symbols are actually there. With nm I can find those. Why do I only get question marks? Is this only because the libraries are compiled with optimization? Isn't it possible to debug with libraries in release mode?

推荐答案

损坏的堆栈 note可能是你的问题。它看起来像一个返回地址或虚拟表条目，或者某些东西被零覆盖，然后控制被转移到那里。即使您有符号可用，那些地址也不指向有效的符号。因此，segfault。

The corrupt stack note is probably your problem. It looks like a return address or virtual table entry or something was overwritten with zeros, and then control was transferred there. Even if you have symbols available, those addresses aren't pointing to valid symbols. Hence the segfault.

我不羡慕你的任务。这些是一些最难以追踪的错误，甚至在您进行代码更改以尝试抓住它们时甚至可以移动或暂时消失。您最好的选择通常是像$ code> git bisect 或您的VCS等效于找到引入它的提交。希望不难复制。

I don't envy your task. These are some of the hardest bugs to track down, and can even move or temporarily go away when you make code changes to try and catch them. Your best bet is usually something like git bisect or your VCS equivalent to find the commit that introduced it. Hopefully it isn't too difficult to reproduce.

这篇关于只有在gdb在ARM上报告的回溯中的问号的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！