Linux的fork是否复制寄存器？COW与寄存器隔离机制探究

我了解到fork的写时复制（COW）机制，甚至听说它作用于寄存器，于是通过GDB做了验证实验：

(gdb) info inferiors
  Num  Description       Connection           Executable
* 1    process 59316     1 (native)           /home/Drew/mycode/a.out
  2    process 59386     1 (native)           /home/Drew/mycode/a.out
(gdb) print( $rdi )
$1 = 18874385
(gdb) set $rdi=42
(gdb) print( $rdi )
$2 = 42
(gdb) inferior 2
[Switching to inferior 2 [process 59386] (/home/Drew/mycode/a.out)]
[Switching to thread 2.1 (process 59386)]
#0  0x00002aaaab090291 in fork () from /lib64/libc.so.6
(gdb) print( $rdi )
$3 = 18874385

实验可见，修改父进程的rdi寄存器后，切换到子进程查看，rdi仍为fork时的原始值。针对这个现象，我需要明确三个核心问题：

1. Linux是否会以任何方式（包括COW）复制寄存器？ #

Linux在fork时会完整复制寄存器状态，但和COW机制无关——COW是针对内存页的优化策略，寄存器属于进程上下文的一部分，fork时会直接做独立副本的拷贝。子进程的初始寄存器状态完全继承自fork调用瞬间父进程的寄存器状态。

2. 若是，是通过硬件（如CPU的虚拟机支持）还是软件（如OS将寄存器值存入内存）实现？ #

这是纯软件层面的实现。CPU寄存器是进程上下文的核心组成，Linux内核处理fork时，会先把父进程当前的所有寄存器值保存到内核栈中，接着为子进程创建独立的进程控制块（PCB），并将父进程的寄存器值完整复制到子进程的上下文结构里。当子进程首次被调度执行时，内核会把这些保存的寄存器值重新加载到CPU中，让子进程从fork的返回点开始执行，就像它自身发起了fork调用一样。

现代CPU的虚拟化扩展（如Intel VT-x）仅用于虚拟机场景，和普通进程的寄存器上下文切换没有关系。

3. 若fork不复制寄存器，为何GDB中会出现上述现象？ #

从实验结果就能直接证明fork确实复制了寄存器。你在GDB中修改父进程的rdi是在fork完成之后，此时子进程已经拥有了独立的寄存器上下文副本——子进程的寄存器状态定格在fork发生的那一刻，之后父进程对寄存器的任何修改都不会影响子进程，因为两者的寄存器上下文完全独立，内核通过调度切换来保证每个进程运行时拥有专属的寄存器状态。

内容的提问来源于stack exchange，提问作者PkDrew