`[stack]`，`[vdso]`和`[vsyscall]`mmaps從哪裏來？

Question

考慮下面的程序針對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條目的（一個地圖。出）。 （即使我每隔一段時間除去這個標題和代碼，都會觀察到相同的地圖。）execve(2)調用fs/binfmt_elf.c中的ELF處理程序，它讀取程序標題並調用該文件上的mmap。

我不明白的是其他三個來自哪裏（stack，vdso，vsyscall）。它們在ELF文件中沒有提及，所以Linux內核默認情況下必須設置這三個「匿名」或「特殊」映射。

我的問題是內核代碼（或如何）Linux內核創建這些其他三個地圖的位置？他們是否繼承了execve？我似乎無法看到他們創建的地方在fs/exec.c。

Answer 1

它們是內核在將文件加載到內存中運行時自動創建的。

爲[vdso]和[vsyscall]的精確控制流動是難以遵循，因爲有各種定義和函數名稱重新定義爲取決於內核是32位還是64位，但宏的一些相關的程序包括：

• load_elf_binary在fs/binfmt_elf.c這就要求arch_setup_additional_pages
• arch_setup_additional_pages在arch/x86/vdso/vma.c
• arch_setup_additional_pages在arch/x86/vdso/vdso32-setup.c

的[stack]映射不是ELF特定並且通過fs/exec.c__bprm_mm_init其由execve代碼調用其調用的格式特定加載器之前創建。