【问题标题】:User-space address at 0xfff<something>0xfff<something> 处的用户空间地址
【发布时间】:2018-11-08 15:29:21
【问题描述】:

我正在 gdb 上调试一个简单的程序,我看到堆栈帧内的局部变量地址如下所示 -- 0xffffbc10、0xffffc340 等。

据我了解,内核空间地址占用0xffffffff 到0xcfffffff,而用户空间地址从0xbfffffff 开始。

为什么会出现这种差异?

编辑:请注意,我已经关闭了虚拟地址空间随机化、堆栈保护器,并且正在使用 -m32 进行编译。如果有帮助,这是我的编译命令:

gcc -m32 -z execstack -fno-stack-protector -ggdb -static test.c -o test

【问题讨论】:

  • 首先,您在gdb 中看到的地址肯定是虚拟地址。假设每个系统上的每个内核都占用相同的地址空间听起来很危险。
  • 我知道这些是虚拟地址。请查看编辑——这会改变你的答案吗?
  • 是的。我不知道内核保留的虚拟地址空间。我知道(我认为)进程可以并且确实有重叠的虚拟地址,但是我猜进程虚拟地址不会与内核虚拟地址重叠?我需要做一些研究。

标签: c gdb virtual-address-space


【解决方案1】:

如果您在 64 位主机(和 64 位内核)上运行 32 位程序,则整个 32 位地址空间通常可供应用程序使用。原则上,这在 32 位内核上也是可能的,但 Linux 和(所有?)其他主要内核保留部分虚拟地址空间,以使用户和内核模式之间的切换更有效。

32 位程序只有 3GB 虚拟地址空间的假设是无效的,但由于一些遗留程序错误地假设了这一点,Linux“个性”系统允许您模拟这种行为来运行它们。它可以通过setarch 命令的-3 选项访问。

【讨论】:

    猜你喜欢
    • 2019-07-03
    • 2016-06-02
    • 1970-01-01
    • 1970-01-01
    • 2019-11-06
    • 2018-04-23
    • 1970-01-01
    • 2012-08-16
    • 2015-02-09
    相关资源
    最近更新 更多