linux – `[stack]`,`[vdso]`和`[vsyscall]`mmaps来自哪里？
发布时间：2020-12-14 00:52:45 所属栏目：Linux 来源：网络整理
导读：考虑以下针对 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 0000000
|
考虑以下针对
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 [stack]映射不是特定于ELF的,并且由fs / exec.c中的__bprm_mm_init创建,它在调用特定于格式的加载器之前由execve代码调用. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |