堆栈参数从堆栈中的错误内存地址读取

Question

我试图在ARM架构上调试进程核心转储。

这是一个用C编写的电信堆栈软件。这个过程是单线程的。

通过gdb进行的某些调试表明，堆栈参数（局部变量或函数参数）正从正确位置的固定偏移量（8字节）的内存位置读取。

下面是一些调试信息：

(gdb) p localParam_p 
$16 = (UInt8 *) 0xbe <Address 0xbe out of bounds> 

(gdb) x /16wx &localParam_p 
0x7ea5c774:  0x000000be  0x00000010  0x94dc788c  0x00000000 

正确（预期）值是存储在一个存储器位置0x7ea5c77c（在上面的输出第三字）

这里0x94dc788c是另一个例子：

(gdb) p localParam2 
$18 = 0 

(gdb) x /16wx &localParam2 
0x7ea5c770:  0x00000000  0x000000be  0x00000010  0x94dc788c 

addrLen的预期值是0x10（以上第三个字）。

我可以在堆栈帧中看到与其他本地变量相同的问题。

请帮忙！

Valgrind不能在此系统上使用。

这个过程只在几天的时间内崩溃一次，再现步骤还未知。

Answer 1

我对这种事情的反应是怀疑编译器的debuginfo错误。它也可能是一个gdb的错误。如果我有这个问题，这是我会做的：

首先，确保我有最新版本的gdb;如果没有升级到最新版本。

如果没有工作，使矮位置拆卸：

maint set dwarf2 always-disassemble on 

然后询问变量的有问题的位置：

info addr localParm2 

这将转储侏儒表达式表示在GDB认为变量是位于。 DWARF表达式使用一种简单的堆栈机器语言，您将不得不深入DWARF标准，也许需要一些GCC扩展文档（在GCC wiki上）来理解这一点。

如果您不使用DWARF - 那么您应该这些天，这是一个很好的开始。

这是我期望找到该错误的地方。而且，如果是这样，唯一的答案就是您需要修复编译器，无论是通过升级还是通过调试那里的问题。

也有可能编译器输出是正确的，并且你已经发现了一个gdb的bug。不过，我认为这是不太可能的，因为gdb中的位置表达式代码已经相当好地运用了。

还值得仔细检查debuginfo是否与您正在调试的程序相匹配。而且，可能需要查看您正在使用的编译器是否存在此区域中的任何已知错误。