linux – `[stack]`,`[vdso]`和`[vsyscall]`mmaps来自哪里？

考虑以下针对 Linux x86_64的程序：

inf.s：

.global _start
    .text
_start:
    jmp _start

这基本上是一个无限循环.

如果我链接并删除它,我得到一个ELF可执行文件：

$gcc -nostdlib inf.s

$./a.out &

[1] 15862

$cat /proc/15862/maps

00400000-00401000 r-xp 00000000 fc:00 11404632           a.out
7fffacdb8000-7fffacdd9000 rwxp 00000000 00:00 0          [stack]
7fffacddd000-7fffacdde000 r-xp 00000000 00:00 0          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0  [vsyscall]

在ELF可执行文件中,第一个程序头LOAD包含占上述mmaps(a.out)中第一个条目的映射. (即使我删除每个但是这个头和代码都会观察到相同的映射.)execve(2)调用fs / binfmt_elf.c中的ELF处理程序,它读取程序头并在文件上调用mmap.

我不明白的是其他三个来自哪里(stack,vdso,vsyscall).它们未在ELF文件中提及,因此Linux内核必须默认设置这三个“匿名”或“特殊”映射.

我的问题是内核代码(或如何)Linux内核创建其他三个映射？他们是否继承了这个人？我似乎无法看到它们在fs / exec.c中的位置.

解决方法

它们是在将文件加载到内存中以运行它时由内核自动创建的.

[vdso]和[vsyscall]的精确控制流程难以理解,因为根据内核是32位还是64位而有一些相关例程包括以下各种函数名称定义和重新定义为宏.

> fs / binfmt_elf.c中的load_elf_binary,它调用arch_setup_additional_pages
> arch / x86 / vdso / vma.c中的arch_setup_additional_pages
> arch / x86 / vdso / vdso32-setup.c中的arch_setup_additional_pages

[stack]映射不是特定于ELF的,并且由fs / exec.c中的__bprm_mm_init创建,它在调用特定于格式的加载器之前由execve代码调用.