我正在使用带有ARM cortex_A9_MPCORE处理器的开发板（雪球），运行带有3.0.8+内核的linux。我使用GDB和openocd进行调试。
我正在寻找一种方法来查找用户模式进程的地址空间，尤其是文本段和用户模式堆栈。
首先我查看了/ proc /“PID”/ maps，例如我正在为其中一个进程运行此输出：
# cat /proc/1124/maps
00008000-000d5000 r-xp 00000000 b3:02 181 /system/bin/lbsd
000d5000-000f8000 rw-p 000cd000 b3:02 181 /system/bin/lbsd
000f8000-0014a000 rw-p 00000000 00:00 0 [heap]
0014a000-0014c000 rw-p 00000000 00:00 0 [heap]
.
.
.
b0001000-b0009000 r-xp 00001000 b3:02 183 /system/bin/linker
b0009000-b000a000 rw-p 00009000 b3:02 183 /system/bin/linker
b000a000-b0015000 rw-p 00000000 00:00 0
bea00000-bea21000 rw-p 00000000 00:00 0 [stack]
ffff0000-ffff1000 r-xp 00000000 00:00 0 [vectors]
然后使用GDB我编写了一个脚本，用于解析板上运行的任务列表，从init_task开始，对于每个任务，它获取task_struct中找到的mm_struct的值，然后提取start_code，end_code和start_stack的值。最后，脚本解析mmap指向的不同内存区域。当电路板处于调试状态时脚本运行，皮质a9的两个核心都停止运行
以下是与上述相同过程的GDB脚本的输出：
taskaddr 0xdf29f140
Name: lbsd
mm start text 8000
mm end text d4ba4
mm start stack bee63df0
####MEMORY REGIONS#####
vm_start 0x8000
vm_end 0xd5000
vm_flags 0x8001875
-----------------------
vm_start 0xd5000
vm_end 0xf8000
vm_flags 0x8101873
-----------------------
vm_start 0xf8000
vm_end 0x14a000
vm_flags 0x100073
-----------------------
vm_start 0x14a000
vm_end 0x14c000
vm_flags 0x100073
-----------------------
.
.
.
-----------------------
vm_start 0xb0001000
vm_end 0xb0009000
vm_flags 0x8000875
-----------------------
vm_start 0xb0009000
vm_end 0xb000a000
vm_flags 0x8100873
-----------------------
vm_start 0xb000a000
vm_end 0xb0015000
vm_flags 0x100073
-----------------------
vm_start 0xbee42000
vm_end 0xbee64000
vm_flags 0x100173
-----------------------
vm_start 0xffff0000
vm_end 0xffff1000
vm_flags 0x40c0055
-----------------------
除了堆栈之外，内存区域与使用的方法匹配，在/ proc方法的输出中，它从bea00000开始，而在mm_struct的start_stack字段中，它在bee63df0，而vm_struct指向的内存区域表示bee42000。有人可以解释这些值的差异吗？
我的第二个问题是关于00008000和000d5000之间的第一个存储区域的值，它对应于该过程的文本部分。我注意到很多进程共享这些地址。内核如何设法获取文本内存区域的真实地址？
在ARM上，堆栈增长了。这意味着堆栈从更高的地址开始。这在vm_flags中可以看到堆栈vma，它有VM_GROWSDOWN位设置。
堆栈vma有一个vm_end的0xbee64000，它正好比start_stack的0xbee63df0高528个字节。发生这种情况是因为在同一个VMA中堆栈顶部之上有一些东西：命令行，环境和辅助向量。
我不知道为什么堆栈（只有它）在/proc/<pid>/maps的不同地址。看看内核源代码，我看到vma可以显示为[stack]当且仅当start_stack在其中时，所以如果你看start_stack时/proc/<pid>/maps是相同的，那vma不能被标记为[stack]。我能想到的唯一解释是，它来自可执行文件的不同运行，并且除了堆栈之外的所有内容都禁用了地址布局随机化。
现在是第二个问题。
当您的进程正在运行时，硬件使用页表从虚拟地址（例如0x8000）映射到页面的物理地址。内核也可以这样做;它有一个指向根页表（pgd）的指针，用于mm_struct中的进程。一旦它有物理页码（pfn），它就可以到达相应的struct page。有一大堆宏和函数可以完成所有这些操作。
但是页面可能会丢失。例如，您的可执行文件的其中一个页面可能尚未出现故障。页面表中该页面的条目将显示为缺失。然后内核查看相应的vma，它给出了vma中的偏移量，有足够的信息从某处获取页面，并将其插入页面表中。