2012-09-15 213 views
2

当我在做“学习C硬路”的例子时,我心想:如何在内存hexdump中找到变量的地址?

我设置int a = 10;但是实际上这个值是10呢?我可以在程序运行时从外部手动访问它吗?

这里是为了演示一个小的C代码片段:

int main (int argc, char const* argv[]) {         

    int a = 10; 
    int b = 5; 
    int c = a + b; 

    return 0; 
} 

我打开了The GNU Project Debugger(GDB),并进入:

break main 
run 
next 2 

从我的理解0x7fff5bffb04内存地址int c。然后我用hexdump -C/dev/mem系统调用将整个内存转储到终端。

现在的问题是我在哪里寻找变量c在这个巨大的十六进制转储?我的希望是,鉴于地址0x7fff5bffb04我可以找到它的价值,这是15。另外,奖励问题,hexdump -C中的每一列代表什么? (我知道,最后一列是ASCII表示)

gdb

hex dump

+2

的'0x7f的...'地址是虚拟的。除非您知道虚拟 - >物理映射,否则不能使用它来查找物理内存转储中的内容。 (第一列是“地址”(自文件开始以来的字节数),最后是ascii表示,中间是数据。) – Mat

+0

@Mat:谢谢。我可以打印物理内存地址,还是可以用十六进制转储虚拟内存而不是物理内存?什么是可能的解决方案? –

+0

为什么你将'argv'定义为'char const * []'? – oldrinb

回答

1

然后我使用hexdump -C/dev/mem系统调用将整个内存转储到终端中。

你的hexdump转储了物理内存地址。地址0x7fff5bffb04虚拟您正在调试的过程中变量的地址。它被映射到一些物理地址地址,但是如果没有检查内核映射表(就像Mat已经在评论中告诉你的那样),你将无法找到它。

要检查虚拟地址空间,请使用/proc/<pid>/mem(因为Barmar已在评论中告诉您)。

但是这整个演习是毫无意义,因为你已经可以检查GDB的虚拟内存,而你不会看到任何你看一下虚拟内存GDB尚未告诉你更方便[1]。

[1]除非你可以看到GDB插入断点,但预计不会明白:-)

1

首先,没有理由为什么值将甚至在RAM存在。除了Likly,这个程序的机器代码只有cpu寄存器中的值。你将不得不有更多的字节(尝试至少512),并将它们设置为随机值,然后您可以在内存转储中搜索。

你更好看看c编译器生成的汇编代码。

+0

“没有理由为什么价值甚至会存在于公羊中” - 是的,有。当程序在没有优化的情况下生成时(这里就是这种情况),大多数编译器会在堆栈上保留空间,并且会实际保存这些值。如果程序是用*优化构建的,那么没有理由在寄存器中存在这些值:任何体面的编译器都会优化所有的分配,因为它们的结果不被使用。 –