ARM 上的 gdb 只报告回溯中的问号
我正在尝试使用 ARM 上的 gdbserver 调试软件以获取崩溃的回溯。不幸的是我只得到问号。我到处都读到这个问题只是与缺少符号有关，但符号并没有从我的库中删除。
如果我尝试使用 file 命令加载客户端中的符号，我会得到：
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 我可以找到那些。为什么我只得到问号？这仅仅是因为库是经过优化编译的吗？是否可以在发布模式下使用库进行调试？
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.
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.
and then, when the crash occurs:
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?)
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
corrupt stack注释可能是您的问题。它看起来像是返回地址或虚拟表条目或被零覆盖的东西，然后控制权被转移到那里。即使您有可用的符号，这些地址也不会指向有效的符号。因此出现了段错误。我不羡慕你的任务。这些是一些最难追踪的错误，当您更改代码以尝试捕获它们时，它们甚至可能会移动或暂时消失。您最好的选择通常是类似于 git bisect 或相当于 VCS 的东西来查找引入它的提交。希望重现起来不会太困难。
The
corrupt stacknote 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.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 bisector your VCS equivalent to find the commit that introduced it. Hopefully it isn't too difficult to reproduce.当您遇到“地址 0 处的 SEGV”问题时，您有时可以使用的一个技巧是手动将返回地址从堆栈顶部弹出到 PC 中，并尝试从那里进行堆栈跟踪。这假设您通过 NULL 指针进行间接调用来访问地址 0，这是访问地址 0 的最常见方法。
现在我对 ARM 不太熟悉，但在 x86 PC 上，您会这样做：
然后再做一次回溯来找出你真正在哪里。
如果您能弄清楚编译器用于 ARM 的调用约定，您应该能够执行类似的操作。
One trick you can sometimes use when you get the "SEGV at address 0" problem is to manually pop the return address from the top of the stack into the pc and trying to do a stack trace from there. This assumes that you got to address 0 by doing an indirect call through a NULL pointer, which is the most common way of getting to address 0.
Now I'm not too familiar with ARM, but on an x86 PC, you would do:
and then do another backtrace to figure out where you really are.
If you can figure out the calling convention used for ARM by your compiler, you should be able to do something similar.