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/maps00400000-004010 考虑以下针对 Linux x86_64的程序：

inf.s：

.global _start    .text_start:    jmp _start

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

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

$gcc -nostdlib inf.s$./a.out &[1] 15862$cat /proc/15862/maps00400000-00401000 r-xp 00000000 fc:00 11404632           a.out7fffacdb8000-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代码调用.

总结

以上是内存溢出为你收集整理的linux – `[stack]`,`[vdso]`和`[vsyscall]`mmaps来自哪里？全部内容，希望文章能够帮你解决linux – `[stack]`,`[vdso]`和`[vsyscall]`mmaps来自哪里？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。