在浏览了一些文本和源代码后fork，我意识到这三个都是通过不同的参数执行的。vforkclonedo_forkfork.c
但究竟如何fork()调用do_fork()..
调用时调用fork()了哪些函数？
do_fork()什么是逐步课程fork()？
问问题
5256 次
1 回答
14
libc和其他系统调用的实现fork()包含调用系统调用的特殊处理器指令。系统调用调用是特定于体系结构的，并且可能是一个相当复杂的主题。
让我们从一个“简单”的例子开始，MIPS：
在 MIPS 上，系统调用是通过 SYSCALL 指令调用的。因此，libc 的实现fork()最终将一些参数放在一些寄存器上，将系统调用号放在 regiter 中v0，并发出一条syscall指令。
在 MIPS 上，这会导致SYSCALL_EXCEPTION（异常编号 8）。启动时，内核将异常 8 与以下处理例程相关联arch/mips/kernel/traps.c:trap_init()：
set_except_vector(8, handle_sys);
因此，当 CPU 因为程序发出指令而接收到异常 8 时， CPU 会转换到内核模式，并在atsyscall开始执行处理程序（对于不同的 32/64 位内核空间/用户空间组合有几个文件）。该例程在系统调用表中查找系统调用号并跳转到相应的函数，在本例中。handle_sys/usr/src/linux/arch/mips/kernel/scall*.Ssys_...()sys_fork()
现在，x86 更加复杂。传统上，Linux 使用中断 0x80 来调用系统调用。这与 x86 门相关联arch/x86/kernel/traps_*.c:trap_init()：
set_system_gate(SYSCALL_VECTOR,&system_call);
x86 处理器具有多个级别（环）的特权（从 80286 开始）。只能通过预定义的门访问（跳转到）较低的环（= 更多特权），这是内核设置的特殊类型的段描述符。因此，当int 0x80调用 an 时，产生了一个中断，CPU 查找一个名为 IDT（Interrupt Descriptor Table）的特殊表，发现它有一个门（x86 中的陷阱门，x86-64 中的中断门），并过渡到环 0，在/处开始执行system_call/ia32_syscall处理程序（分别针对 x86/x86_64）。arch/x86/kernel/entry_32.Sarch/x86/ia32/ia32entry.S
但是，自 Pentium Pro 以来，有另一种调用系统调用的方法：使用SYSENTER指令（AMD 也有自己的SYSCALL指令）。这是调用系统调用的更有效方式。这种“较新”机制的处理程序设置为arch/x86/vdso/vdso32-setup.c:syscall32_cpu_init()：
#ifdef CONFIG_X86_64
[...]
void syscall32_cpu_init(void)
{
if (use_sysenter < 0)
use_sysenter = (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL);
/* Load these always in case some future AMD CPU supports
SYSENTER from compat mode too. */
checking_wrmsrl(MSR_IA32_SYSENTER_CS, (u64)__KERNEL_CS);
checking_wrmsrl(MSR_IA32_SYSENTER_ESP, 0ULL);
checking_wrmsrl(MSR_IA32_SYSENTER_EIP, (u64)ia32_sysenter_target);
wrmsrl(MSR_CSTAR, ia32_cstar_target);
}
[...]
#else
[...]
void enable_sep_cpu(void)
{
int cpu = get_cpu();
struct tss_struct *tss = &per_cpu(init_tss, cpu);
if (!boot_cpu_has(X86_FEATURE_SEP)) {
put_cpu();
return;
}
tss->x86_tss.ss1 = __KERNEL_CS;
tss->x86_tss.sp1 = sizeof(struct tss_struct) + (unsigned long) tss;
wrmsr(MSR_IA32_SYSENTER_CS, __KERNEL_CS, 0);
wrmsr(MSR_IA32_SYSENTER_ESP, tss->x86_tss.sp1, 0);
wrmsr(MSR_IA32_SYSENTER_EIP, (unsigned long) ia32_sysenter_target, 0);
put_cpu();
}
[...]
#endif /* CONFIG_X86_64 */
以上使用机器特定寄存器 (MSR) 进行设置。处理程序例程是ia32_sysenter_targetand ia32_cstar_target（最后一个仅适用于 x86_64）（in arch/x86/kernel/entry_32.Sor arch/x86/ia32/ia32entry.S）。
选择要使用的系统调用机制
linux 内核和 glibc 有一种机制可以在调用系统调用的不同方式之间进行选择。
内核为每个进程设置了一个虚拟共享库，称为 VDSO（虚拟动态共享对象），您可以在以下输出中看到cat /proc/<pid>/maps：
$ cat /proc/self/maps
08048000-0804c000 r-xp 00000000 03:04 1553592 /bin/cat
0804c000-0804d000 rw-p 00003000 03:04 1553592 /bin/cat
[...]
b7ee8000-b7ee9000 r-xp b7ee8000 00:00 0 [vdso]
[...]
这个 vdso 包含一个适当的系统调用调用序列，用于正在使用的 CPU，例如：
ffffe414 <__kernel_vsyscall>:
ffffe414: 51 push %ecx ; \
ffffe415: 52 push %edx ; > save registers
ffffe416: 55 push %ebp ; /
ffffe417: 89 e5 mov %esp,%ebp ; save stack pointer
ffffe419: 0f 34 sysenter ; invoke system call
ffffe41b: 90 nop
ffffe41c: 90 nop ; the kernel will usually
ffffe41d: 90 nop ; return to the insn just
ffffe41e: 90 nop ; past the jmp, but if the
ffffe41f: 90 nop ; system call was interrupted
ffffe420: 90 nop ; and needs to be restarted
ffffe421: 90 nop ; it will return to this jmp
ffffe422: eb f3 jmp ffffe417 <__kernel_vsyscall+0x3>
ffffe424: 5d pop %ebp ; \
ffffe425: 5a pop %edx ; > restore registers
ffffe426: 59 pop %ecx ; /
ffffe427: c3 ret ; return to caller
在arch/x86/vdso/vdso32/使用int 0x80,sysenter和的实现中，syscall内核会选择合适的实现。
为了让用户空间知道有一个 vdso 以及它的位置，内核在辅助向量中设置AT_SYSINFO和条目（ ，第 4 个参数，用于将一些信息从内核传递给新启动的进程）。指向 vdso 的 ELF 头，指向 vsyscall 实现：AT_SYSINFO_EHDRauxvmain()argc, argv, envpAT_SYSINFO_EHDRAT_SYSINFO
$ LD_SHOW_AUXV=1 id # tell the dynamic linker ld.so to output auxv values
AT_SYSINFO: 0xb7fd4414
AT_SYSINFO_EHDR: 0xb7fd4000
[...]
glibc 使用此信息来定位vsyscall. 它将它存储到动态加载器 global_dl_sysinfo中，例如：
glibc-2.16.0/elf/dl-support.c:_dl_aux_init():
ifdef NEED_DL_SYSINFO
case AT_SYSINFO:
GL(dl_sysinfo) = av->a_un.a_val;
break;
#endif
#if defined NEED_DL_SYSINFO || defined NEED_DL_SYSINFO_DSO
case AT_SYSINFO_EHDR:
GL(dl_sysinfo_dso) = (void *) av->a_un.a_val;
break;
#endif
glibc-2.16.0/elf/dl-sysdep.c:_dl_sysdep_start()
glibc-2.16.0/elf/rtld.c:dl_main:
GLRO(dl_sysinfo) = GLRO(dl_sysinfo_dso)->e_entry + l->l_addr;
在 TCB（线程控制块）的头部中的一个字段中：
glibc-2.16.0/nptl/sysdeps/i386/tls.h
_head->sysinfo = GLRO(dl_sysinfo)
如果内核是旧的并且不提供 vdso，glibc 提供了一个默认实现_dl_sysinfo：
.hidden _dl_sysinfo_int80:
int $0x80
ret
当针对 glibc 编译程序时，根据情况，在调用系统调用的不同方式之间做出选择：
glibc-2.16.0/sysdeps/unix/sysv/linux/i386/sysdep.h:
/* The original calling convention for system calls on Linux/i386 is
to use int $0x80. */
#ifdef I386_USE_SYSENTER
# ifdef SHARED
# define ENTER_KERNEL call *%gs:SYSINFO_OFFSET
# else
# define ENTER_KERNEL call *_dl_sysinfo
# endif
#else
# define ENTER_KERNEL int $0x80
#endif
int 0x80← 传统方式call *%gs:offsetof(tcb_head_t, sysinfo)←%gs指向 TCB，所以它通过指向存储在 TCB 中的 vsyscall 的指针间接跳转。这对于编译为 PIC 的对象是首选。这需要 TLS 初始化。对于动态可执行文件，TLS 由 ld.so 初始化。对于静态 PIE 可执行文件，TLS 由 __libc_setup_tls() 初始化。call *_dl_sysinfo← this 通过全局变量间接跳转。这需要重新定位 _dl_sysinfo，因此可以避免编译为 PIC 的对象。
所以，在 x86 中：
fork()
↓
int 0x80 / call *%gs:0x10 / call *_dl_sysinfo
| ↓ ↓
| (in vdso) int 0x80 / sysenter / syscall
↓ ↓ ↓ ↓
system_call | ia32_sysenter_target | ia32_cstar_target
↓
sys_fork()
于 2012-07-19T23:03:37.200 回答