Memory 有没有办法检查GDB中的内核空间？

我在这里可能有一个更基本的误解，因此我将概述所有内容：

我想更好地了解程序在内存中的布局。从一开始，我做了一些简单的程序，并在GDB中打开它们，从更实际的意义上看东西放在哪里：

0x0 - 0x08048000 = ??
0x08048000 = Start .text section
0x08048000 = PLT
0x08048300 = _start
0x08048400 = main
0x08048480 = other functions
0x0804a000 = GOT
0x0804a020 = Start .data section
0x0804a028 = Start .bss section
(random offset)
0x0804b008 = Start heap
...
0xf7?????? = Start memory mapping section
0xf7e50000 = #included library function definitions
0xf7ff0000 = Linux dynamic loader
(random offset)
0xffffd010 = Top of stack (grows negatively)
(random offset)

我知道这些地址中有很多可能会发生变化，但它通过给事物分配数字帮助我将其形象化

无论如何，在上面源代码中显示的下图中，在程序地址空间的顶部有一个专用于内核空间的块：

但是它允许有整整一个千兆字节！我检查的程序堆栈的顶部是0xffffd010，为以后与内核相关的事情留下了很少的空间。真的就这些吗？它是否曾经增长，将虚拟地址空间中的其余程序段推得更近？更重要的是，我如何检查它和玩它

我检查的程序堆栈的顶部是0xffffd010，为以后与内核相关的事情留下了很少的空间。真的就这些吗

您的堆栈位于内存的顶部-没有内核映射。这表明以下情况之一：

• 您在64位系统上运行的是32位二进制文件，因此内核位于64位空间之外，您无法看到它
• 您正在运行一个带有applicated的奇怪内核，因此内核（再次）位于一个完全独立的地址空间中
• 您使用的是非x86体系结构，它始终为用户和系统进程提供单独的地址空间（我相信是PowerPC吧？）

要了解地址空间的实际外观，请查看进程运行时的

/proc/$pid/maps

它是否曾经增长，将虚拟地址空间中的其余程序段推得更近

否。内核映射的大小被编译到内核中，并且在运行时不会更改。（可以将其配置为2GB/2GB，而不是3GB/1GB，但这非常少见。）

更重要的是，我如何检查它和玩它

---

你不能-至少，不能从用户空间。这就是内核所在的位置。

您的第一个猜测完全正确。我正在64位Ubuntu上运行一个程序，该程序是使用-m32标志编译的。非常感谢。