程序人生-Hello’s P2P

计算机系统原理

大作业

题 目 ++++程序人生-Hello++++ ++++'++++ ++++s P2P++++

专 业 ++++AI先进技术领军班++++

学　　 号 ++++2024113013++++

班 级 ++++24Q0305++++

学 生 ++++王新桐++++

指 导 教 师 ++++史先俊++++

计算学部

202 5 年9月

摘 要

本文以 hello 程序为研究对象，围绕其 "从程序到进程（P2P）" 与 "从无到无（O2O）" 的完整生命周期展开，系统剖析计算机系统底层工作机制。在程序构建阶段，详细阐述预处理、编译、汇编、链接四大流程：预处理通过头文件展开、宏替换生成纯净源码文件 hello.i；编译将 hello.i 转换为汇编代码 hello.s，完成高级语言到硬件指令的逻辑映射；汇编把 hello.s 转换为含机器码的可重定位目标文件 hello.o，并记录符号与重定位信息；链接整合 hello.o 与系统库，解决符号依赖与地址重定位，生成可执行文件 hello。在进程运行阶段，分析 Shell 通过 fork 创建子进程、execve 加载程序的过程，结合内存管理机制，包括段式、页式地址转换、TLB 加速、三级 Cache 优化与I/O管理逻辑，揭示虚拟地址到物理地址的转换、缺页中断处理、设备抽象等核心原理。

****关键词：****Hello 程序；P2P；计算机系统；内存管理；I/O 接口

（摘要0分，缺失-1分， 根据内容精彩称都酌情加分0-1分 ）

自媒体发表截图

目 录

[++++第1章 概述++++](#第1章 概述)

[++++1.1 Hello简介++++](#1.1 Hello简介)

[++++1.2 环境与工具++++](#1.2 环境与工具)

[++++1.3 中间结果++++](#1.3 中间结果)

[++++1.4 本章小结++++](#1.4 本章小结)

[++++第2章 预处理++++](#第2章 预处理)

[++++2.1 预处理的概念与作用++++](#2.1 预处理的概念与作用)

++++2.2在Ubuntu下预处理的命令++++

[++++2.3 Hello的预处理结果解析++++](#2.3 Hello的预处理结果解析)

[++++2.4 本章小结++++](#2.4 本章小结)

[++++第3章 编译++++](#第3章 编译)

[++++3.1 编译的概念与作用++++](#3.1 编译的概念与作用)

[++++3.2 在Ubuntu下编译的命令++++](#3.2 在Ubuntu下编译的命令)

[++++3.3 Hello的编译结果解析++++](#3.3 Hello的编译结果解析)

[++++3.4 本章小结++++](#3.4 本章小结)

[++++第4章 汇编++++](#第4章 汇编)

[++++4.1 汇编的概念与作用++++](#4.1 汇编的概念与作用)

[++++4.2 在Ubuntu下汇编的命令++++](#4.2 在Ubuntu下汇编的命令)

[++++4.3 可重定位目标elf格式++++](#4.3 可重定位目标elf格式)

[++++4.4 Hello.o的结果解析++++](#4.4 Hello.o的结果解析)

[++++4.5 本章小结++++](#4.5 本章小结)

[++++第5章 链接++++](#第5章 链接)

[++++5.1 链接的概念与作用++++](#5.1 链接的概念与作用)

[++++5.2 在Ubuntu下链接的命令++++](#5.2 在Ubuntu下链接的命令)

[++++5.3 可执行目标文件hello的格式++++](#5.3 可执行目标文件hello的格式)

[++++5.4 hello的虚拟地址空间++++](#5.4 hello的虚拟地址空间)

[++++5.5 链接的重定位过程分析++++](#5.5 链接的重定位过程分析)

[++++5.6 hello的执行流程++++](#5.6 hello的执行流程)

[++++5.7 Hello的动态链接分析++++](#5.7 Hello的动态链接分析)

[++++5.8 本章小结++++](#5.8 本章小结)

[++++第6章 hello进程管理++++](#第6章 hello进程管理)

[++++6.1 进程的概念与作用++++](#6.1 进程的概念与作用)

[++++6.2 简述壳Shell-bash的作用与处理流程++++](#6.2 简述壳Shell-bash的作用与处理流程)

[++++6.3 Hello的fork进程创建过程++++](#6.3 Hello的fork进程创建过程)

[++++6.4 Hello的execve过程++++](#6.4 Hello的execve过程)

[++++6.5 Hello的进程执行++++](#6.5 Hello的进程执行)

[++++6.6 hello的异常与信号处理++++](#6.6 hello的异常与信号处理)

++++6.7本章小结++++

[++++第7章 hello的存储管理++++](#第7章 hello的存储管理)

[++++7.1 hello的存储器地址空间++++](#7.1 hello的存储器地址空间)

[++++7.2 Intel逻辑地址到线性地址的变换-段式管理++++](#7.2 Intel逻辑地址到线性地址的变换-段式管理)

[++++7.3 Hello的线性地址到物理地址的变换-页式管理++++](#7.3 Hello的线性地址到物理地址的变换-页式管理)

[++++7.4 TLB与四级页表支持下的VA到PA的变换++++](#7.4 TLB与四级页表支持下的VA到PA的变换)

[++++7.5 三级Cache支持下的物理内存访问++++](#7.5 三级Cache支持下的物理内存访问)

[++++7.6 hello进程fork时的内存映射++++](#7.6 hello进程fork时的内存映射)

[++++7.7 hello进程execve时的内存映射++++](#7.7 hello进程execve时的内存映射)

[++++7.8 缺页故障与缺页中断处理++++](#7.8 缺页故障与缺页中断处理)

++++7.9动态存储分配管理++++

++++7.10本章小结++++

[++++第8章 hello的IO管理++++](#第8章 hello的IO管理)

[++++8.1 Linux的IO设备管理方法++++](#8.1 Linux的IO设备管理方法)

[++++8.2 简述Unix IO接口及其函数++++](#8.2 简述Unix IO接口及其函数)

[++++8.3 printf的实现分析++++](#8.3 printf的实现分析)

[++++8.4 getchar的实现分析++++](#8.4 getchar的实现分析)

++++8.5本章小结++++

++++结论++++

++++附件++++

++++参考文献++++

第1章 概述

1.1 Hello简介

根据Hello的自白，利用计算机系统的术语，简述Hello的P2P，020的整个过程。

P2P过程

Program：用户编写hello.c源码，该程序以文本形式存在，包含代码指令、数据定义等静态信息，此时仅为存储在磁盘上的静态文件，未与计算机硬件资源产生交互。

预处理阶段：预处理器对hello.c进行处理，展开宏定义、处理头文件包含、删除注释等，生成预处理后的.i文件，完成源码层面的静态优化与整合。

编译阶段：编译器将预处理后的文件转换为汇编语言程序.s文件，过程中进行语法分析、语义分析、优化，将高级语言指令映射为汇编指令集。

汇编阶段：汇编器将汇编语言程序转换为机器语言目标文件.o文件，每个汇编指令对应CPU可识别的二进制指令，目标文件包含代码段、数据段等，但尚未解决外部符号引用。

链接阶段：链接器将目标文件与标准库、其他目标文件合并，解析外部符号引用，重定位代码和数据的地址，生成可执行文件，此时文件具备运行能力但仍处于磁盘静态存储状态。

Process：用户通过Bash shell执行可执行文件，操作系统通过fork系统调用创建新进程，为进程分配PID、进程控制块等核心资源；随后通过execve系统调用将可执行文件加载到内存，OS利用mmap机制映射代码段、数据段、堆栈段到虚拟地址空间；存储管理模块通过TLB、四级页表完成虚拟地址到物理地址的转换，结合三级Cache提升内存访问效率；CPU通过时间片轮转机制为进程分配执行资源，按流水线、取指-译码-执行流程运行指令；I/O管理模块协调键盘输入、显卡输出等设备，信号处理机制保障进程与OS的交互，最终在屏幕上输出结果。

进程终止：程序执行完成后，OS回收进程占用的CPU、内存、I/O等资源，完成"收尸"操作，进程生命周期结束。

O2O过程

初始状态Zero-0：hello.c未编写前，不存在对应的程序实体，计算机系统中无相关代码、数据及进程资源，处于"零"状态。

创建与运行：从用户编写源码开始，历经预处理、编译、汇编、链接生成可执行文件，再到OS创建进程、加载运行、硬件执行，完成从无到有的完整生命周期，期间整合了编辑器、编译器、汇编器、链接器、OS、CPU、RAM、I/O设备等计算机系统核心组件的协同工作。

终止状态Zero-0：进程执行完毕后，OS回收所有分配的资源，可执行文件仍保留在磁盘，进程相关的内存映射、PCB、CPU时间片等资源全部释放，系统回归到无该进程运行的"零"状态，实现"赤条条来去无牵挂"的闭环。

1.2 环境与工具

1.2.1 硬件环境

CPU：Intel Core i7-12700K，x86-64 架构，12 核心 20 线程，基础频率 3.6GHz

内存：32GB DDR5-5600

存储：1TB 固态硬盘

操作系统：Ubuntu 22.04 LTS

1.2.2 软件与开发工具

编译工具链：GCC

调试工具：GDB

文件分析工具：readelf 、objdump 进程管理工具：ps、pstree、strace

1.3 中间结果

hello.c：存储 hello 程序的 C 语言源码，包含参数校验、循环打印、休眠与等待输入逻辑。

hello.i：预处理后的中间文件，展开 stdio.h/unistd.h/stdlib.h 头文件，删除注释与宏替换。

hello.s：汇编语言文件，将 C 语言逻辑转换为 x86-64 架构的汇编指令，包含代码段与数据段定义。

hello.o：可重定位目标文件，存储机器码、符号表与重定位条目，未解决外部依赖。

Hello：可执行文件，整合 hello.o 与系统库，分配虚拟地址，支持直接加载运行。

1.4 本章小结

本章围绕 hello 程序的 "P2P" 与 "O2O" 生命周期核心概念，明确研究范围从源码编写延伸至进程终止。通过梳理硬件环境与工具链，为后续实验提供实操基础；同时列出各阶段中间文件及其作用，建立 "源码→中间文件→可执行文件" 的清晰关联。本章作为报告的开篇，不仅界定了研究边界与技术栈，更通过 "从无到有再到无" 的 O2O 逻辑，为后续章节拆解预处理、编译、进程管理等环节奠定框架，实现理论概念与实验实操的初步衔接。

（第1章0.5分）

第2章 预处理

2.1 预处理的概念与作用

2.1.1 预处理 的 概念

预处理是C/C++编译流程的首个独立阶段，由预处理器单独完成，它先于编译器的语法分析、代码优化等核心工作。它不理解代码语法结构，仅以"文本替换+辅助加工"的模式对源码进行预处理，最终生成以.i为后缀的纯净中间源码文件，并自动移除所有预处理指令，为后续编译阶段提供统一、规范的输入。

2.1.2 预处理 的 作用

头文件包含：整合外部接口通过#include指令，将指定头文件的全部内容原样嵌入当前源码对应位置，整合外部函数声明、宏定义、数据类型定义等接口，避免手动复制代码，实现代码复用，减少开发冗余，确保编译器能识别printf等外部函数。

宏定义与替换：通过#define指令实现文本级字符串替换，分为两种类型：常量宏：统一管理字面常量，便于后续批量修改；宏函数：简化重复代码片段，无普通函数调用的栈帧创建、销毁开销，提升运行效率。

条件编译：通过#ifdef、#ifndef、#if、#endif等指令，根据预设条件选择性保留或剔除源码。未满足条件的代码会被直接移除，不进入后续编译流程，可实现调试模式与发布模式切换、跨平台开发适配，同时减少最终可执行文件体积。

注释删除：自动移除源码中的单行注释和多行注释，剔除对编译和运行无意义的内容，减少源码体积，提升后续编译流程的效率。

宏取消定义：通过#undef指令取消已定义的宏。

内置宏支持：提供__LINE__、__FILE__等内置宏，用于调试日志和错误提示。

防头文件重复包含：通过 #ifndef + #define + #endif 组合，避免头文件重复嵌入导致的宏重定义、函数声明重复等编译错误。

2.2在Ubuntu下预处理的命令

在ubuntu下预处理命令为：gcc -E [输入文件.c] -o [输出文件.i]

以下是hello.c的预处理过程展示

图2.1.1 hello.c的预处理过程

可以看到输入gcc -E hello.c -o hello.i后，在当前文件夹下生成了hello.i文件，其中包含了hello.c预处理后的结果。

2.3 Hello的预处理结果解析

预处理结果整体特征：文件规模显著增大。原hello.c仅20余行，预处理后扩展至数千行；无预处理指令残留。所有以 # 开头的指令均被处理并移除，仅保留加工后的代码逻辑；语法仍为C语言。未涉及汇编或机器码转换，本质是对源码的"预处理优化"，为后续编译阶段提供标准化输入。

预处理核心操作的结果体现：头文件完全展开。hello.c中包含3个系统头文件：#include <stdio.h>、#include <unistd.h>、#include <stdlib.h>，预处理时被完整嵌入到 hello.i中，对应文件内的三大代码块：

stdio.h展开块：包含标准输入输出库的核心定义，如FILE结构体、printf、getchar函数声明、size_t、va_list等类型定义，确保后续代码中调用printf和getchar时，编译器能识别函数接口。

unistd.h展开块：嵌入系统调用相关的声明与类型定义，核心是sleep函数声明，为hello.c中sleep(atoi(argv[4]))的调用提供接口支持；同时包含pid_t、uid_t等系统类型定义，支撑操作系统层面的资源管理。

stdlib.h展开块： 嵌入通用工具函数的声明，关键是atoi函数和exit函数的声明，分别对应hello.c中"将命令行参数转换为整数"和"参数错误时退出程序"的逻辑。

同时，展开的头文件中还包含嵌套依赖，如stdio.h依赖 bits/libc-header-start.h、features.h。预处理器会递归展开所有依赖文件，确保所有外部接口定义完整。

在预处理文件中注释完全移除。hello.c中的注释在hello.i中被全部删除，仅保留有效代码逻辑。如：原hello.c中"// 程序运行过程中可以按键盘..."类注释无任何残留，main函数内的代码直接以"int main intargc,char * argv[]{ int i; ..."开头，消除对编译无意义的冗余信息。

在预处理文件中还包含预定义宏与行号标识。在hello.i开头包含一系列以 # 开头的行标识，如：# 0 "hello.c"：标识后续代码源自hello.c；# 1 "/usr/include/stdc-predef.h" 1 3 4：标识当前代码块来自stdc-predef.h头文件，且具备"系统级包含"属性，其中数字"1 3 4"为预处理器内部标识，分别代表"系统头文件""包含 Guards""C99标准兼容"。

2.4 本章小结

本章聚焦 hello 程序的预处理阶段，明确其核心是 "文本级加工与接口整合"。通过在 Ubuntu 环境下执行gcc -E hello.c -o hello.i命令，成功生成预处理文件：原 20 余行的 hello.c 扩展至数千行，核心变化包括 stdio.h/unistd.h/stdlib.h 头文件的递归展开、注释的彻底删除、预定义宏与行号标识的添加。预处理阶段未涉及语法分析或指令转换，仅通过 "复制 - 替换" 逻辑为后续编译提供规整、统一的 C 语言输入，解决了 "头文件重复包含""宏定义复用" 等问题。预处理是程序构建的基础环节，其输出质量直接影响编译阶段的指令生成准确性，也为理解 "高级语言如何依赖系统库接口" 提供了直观视角。

（第2章0.5分）

第3章 编译

3.1 编译的概念与作用

编译是 C 语言程序构建流程的核心阶段，承接预处理后的中间文件如hello.i，由编译器完成高级语言到汇编语言的转换。其核心概念是将预处理后规整的 C 语言文本，通过词法分析、语法分析、语义分析及优化处理，翻译成 CPU 可识别的汇编语言程序。

编译阶段的核心作用体现在两方面：一是建立高级语言与机器指令的映射关系，汇编指令与机器指令一一对应，为后续汇编阶段生成机器码奠定基础；二是通过编译优化提升程序执行效率，同时检查代码语法错误，确保程序逻辑的规范性。该阶段是程序从 "人类可读文本" 向 "机器可执行指令" 转换的关键桥梁。

3.2 在Ubuntu下编译的命令

应截图，展示编译过程！

在Ubuntu下编译的命令是gcc -S [输入文件] -o [输出文件.s]

图3.2.1 对hello.i的编译过程

由图可知，对hello.i使用命令，在当前目录下生成了hello.s的文件。

3.3 Hello的编译结果解析

3.3.1 数据类型处理

1.局部变量与函数参数

原程序中的局部变量i、函数参数argc、argv，均存储在栈空间，通过栈基址寄存器%rbp的偏移量定位：

argc：存储于 -20(%rbp) ，编译时通过 movl %edi, -20(%rbp) 将传入的参数值写入栈空间。

argv：存储于 -32(%rbp) ，通过 movq %rsi, -32(%rbp) 将寄存器%rsi中的指针值写入栈空间。

i：存储于 -4(%rbp) ，初始化时通过 movl $0, -4(%rbp) 将立即数0写入栈空间，后续自增操作也针对该地址。

核心逻辑：int类型变量占4字节，指针类型占8字节，编译时严格按数据类型的字节长度分配栈空间，确保内存对齐。

2.字符串常量

原程序中的字符串，如"用法: Hello 学号 姓名 手机号 秒数！\n"、"Hello %s %s %s\n"，编译后存储在 .rodata ，通过符号标签标识地址：

.LC0：对应"用法: Hello 学号 姓名 手机号 秒数！\n"，编译指令为.string "\347\224\250\346\263\225: Hello ..."，存储于 .rodata 段，因字符串长度超过8字节，通过 .align 8 指令实现8字节对齐。

.LC1：对应 "Hello %s %s %s\n" ，同样存储于 .rodata 段，通过leaq .LC1(%rip), %rax指令加载地址，供printf 函数调用时使用。

核心逻辑：字符串常量为只读数据，编译时放入.rodata段而非可写的.data段，避免程序运行中被意外修改。

3.3.2 核心操作映射

hello.c中的赋值、算术运算、函数调用等操作，编译后转换为对应的汇编指令，具体映射关系如下：

1.赋值操作

原程序中i=0：编译为movl 0, -4(%rbp)，movl为32位数据传输指令，0为立即数0，-4(%rbp)为i的栈地址，实现"将0写入i的内存位置"的操作。

函数参数赋值，以exit(1)中的1为例：编译为movl $1, %edi，%edi是x86-64架构下传递第一个int类型参数的寄存器，将立即数1传入该寄存器，供exit函数调用。

2.算术操作

i++：原程序中for循环的i++，编译为addl 1, -4(%rbp)，addl为32位加法指令，1为增量，-4(%rbp)为i的地址，实现"i的值加1"。

取模运算：原程序注释中"秒数=手机号%5"，虽未显式写出，但编译时若存在该逻辑，如atoi(argv[4])%5，会转换为movl、imull组合指令。

3.函数操作

函数调用：均通过call指令实现地址跳转，参数通过寄存器传递，栈平衡由调用者或被调用者维护：

printf("Hello %s %s %s\n", argv[1], argv[2], argv[3])：

加载字符串地址：leaq .LC1(%rip), %rax → movq %rax, %rdi，其中%rdi传递格式字符串地址。

传递argv[1]：movq -32(%rbp), %rax → addq $8, %rax → movq (%rax), %rax → movq %rax, %rsi，其中%rsi传递argv[1]的地址。

传递argv[2]：movq -32(%rbp), %rax → addq $16, %rax → movq (%rax), %rdx，其中%rdx传递argv[2]的地址。

传递argv[3]：movq -32(%rbp), %rax → addq $24, %rax → movq (%rax), %rcx，其中%rcx传递argv[3]的地址。

调用printf：call printf@PLT，@PLT表示通过过程链接表调用。

sleep(atoi(argv[4]))：

先通过call atoi@PLT将argv[4]转换为int类型，结果存储在%eax中，再通过movl %eax, %edi将结果传入%edi，最后调用call sleep@PLT。

函数返回return 0：

编译为movl $0, %eax。%eax存储函数返回值，，再执行leave和ret指令。

3.3.3 控制流程转换

hello.c中的if-else分支、for循环等控制逻辑，编译后通过"比较指令+跳转指令"组合实现，具体如下：

1.if(argc!=5)分支判断

原程序逻辑：若参数个数不等于5，执行printf错误提示并exit(1)；否则进入循环。

编译后的汇编指令序列：

cmpl $5, -20(%rbp) # 比较argc的值与5

je .L2 # 若argc==5，跳转到.L2

leaq .LC0(%rip), %rax # 加载错误提示字符串地址

movq %rax, %rdi

call puts@PLT # 调用puts输出错误信息

movl $1, %edi

call exit@PLT # 调用exit退出程序

.L2: # 分支跳转目标，当argc==5时进入

movl $0, -4(%rbp) # i=0，循环初始化

2.for(i=0;i<10;i++)循环

原程序逻辑：初始化i=0，判断i<10，若成立则执行循环体printf、sleep，最后i++，重复上述过程。

编译后的汇编指令序列：

.L2:

movl $0, -4(%rbp) # 循环初始化：i=0

jmp .L3 # 跳转到循环条件判断

.L4: # 循环体开始

省略，printf、sleep调用指令，即循环体内容

addl $1, -4(%rbp) # i++：i的值加1

.L3: cmpl $9, -4(%rbp) # 循环条件判断：比较i与9

jle .L4 # 若i<=9，跳转到.L4，否则退出循环

核心优化解析：编译器将i<10优化为i<=9，减少一次循环判断的比较次数；循环通过"jmp .L3→ .L3→ .L4"的标签跳转实现，符合汇编语言的循环结构设计。

3.函数调用后的流程控制

如getchar()调用：原程序中getchar()用于等待键盘输入，编译为call getchar@PLT，调用完成后通过`ret`指令返回`main`函数，继续执行return 0。

核心逻辑：函数调用通过`call`指令跳转到函数入口，执行完成后通过ret指令回到调用点，确保程序流程的连续性。

3.4 本章小结

本章围绕Hello程序的编译过程展开，明确了编译的核心是"将预处理后的C语言代码转换为汇编指令"，其价值在于搭建高级语言与硬件指令的桥梁，同时通过优化提升程序效率。在Ubuntu环境下，通过gcc -S命令可便捷生成汇编文件，实操中需注意参数格式与结果验证。 对hello.s的解析表明，编译器会根据数据类型分配栈空间，将C语言操作映射为对应的汇编指令，并通过"比较+跳转"指令组合实现控制流程。这一过程严格遵循x86-64架构的存储规则与指令集规范，为后续汇编阶段生成可重定位目标文件奠定了基础，是Hello程序从静态Program向动态Process过渡的关键环节。

（第3章2分）

第4章 汇编

4.1 汇编的概念与作用

4.1.1 汇编的核心概念

汇编是计算机程序构建流程中承上启下的关键阶段，特指由汇编器将编译阶段输出的汇编语言源文件，转换为可重定位目标文件的二进制转换过程。

该阶段的核心特征与关键属性如下：

一一对应式转换：与编译阶段不同，汇编指令与机器语言指令存在严格的一一对应关系，汇编器无需进行复杂的语法分析、语义优化或逻辑转换，仅需按照目标CPU架构的指令集规范，完成汇编助记符到二进制机器码的直接映射。

输出文件特性：生成的.o文件为ELF或PE格式的二进制文件，存储着CPU可识别的机器语言代码，但因未解决外部符号引用和内存地址重定位问题，无法直接加载运行，仅具备"可重定位"特性。

无逻辑优化操作：汇编器仅负责指令转换与文件组织，不进行任何代码逻辑优化，优化操作已在编译阶段完成，.s文件中的指令布局与逻辑会完整保留在.o文件的机器码中。

4.1.2 汇编的核心作用

1.实现汇编指令到机器码的精准转换

这是汇编阶段的核心基础作用。汇编语言本质是机器语言的"符号化助记符"，其指令格式、操作数均对应目标CPU的硬件架构规范，汇编器的核心职责就是将这些易读的汇编助记符转换为由0和1组成的二进制机器码。

这些机器码是CPU能够直接读取、译码并执行的底层指令，承载着程序的核心执行逻辑，是高级语言程序最终落地为硬件操作的关键环节。没有汇编阶段的转换，编译生成的汇编指令无法被硬件识别，程序逻辑也无法得到实际执行。

2.收集符号信息，记录重定位条目

汇编器在完成指令转换的同时，会同步完成符号信息收集与重定位条目记录，这是支撑后续链接阶段顺利进行的核心保障：

符号信息收集：汇编器会扫描.s文件，识别并分类记录所有符号信息，包括全局符号、外部符号、局部符号，并将这些符号的名称、类型、地址偏移量等信息存入.o文件的符号表中。

重定位条目记录：对于汇编阶段无法确定实际内存地址的符号，汇编器会在.o文件的重定位表中，记录这些符号在机器码中的位置、符号名称及重定位类型，告知链接器后续需要对这些地址进行修正、填充与绑定。

这一操作解决了"多文件依赖"与"库函数引用"的地址不确定性问题，为链接阶段合并多份.o文件、解析外部依赖提供了关键数据支撑。

3.按标准格式组织文件结构，规范内存布局

汇编器生成的.o文件遵循统一的二进制文件格式，会将不同类型的数据与指令按功能划分到专属的段中，形成规整的文件结构，为后续链接阶段的段合并与系统运行时的内存映射提供标准支持。

通用.o文件的核心段布局由汇编器规划完成，各段功能具有统一规范：

.text段：存储程序的机器码指令，具备执行权限，是程序运行的核心代码区域。

.rodata段：存储只读数据，具备只读权限，防止程序运行中被意外修改。

.data段：存储已初始化的全局变量与静态变量，具备可读可写权限。

.bss段：存储未初始化的全局变量与静态变量，仅记录变量大小与偏移量，不占用实际文件存储空间，程序运行时由系统分配内存并初始化为0。

符号表与重定位表相关段：存储符号信息与重定位条目，为链接阶段提供数据支持。

辅助段：存储字符串表、段名称表等辅助信息，用于解析符号与段的名称标识。

1. 校验汇编指令合法性

汇编器在转换过程中，会对.s文件中的汇编指令进行严格的合法性校验，确保指令符合目标CPU架构的指令集规范，从源头规避无效指令导致的程序运行失败：

指令格式校验：排查拼写错误的指令助记符、参数个数不匹配、操作数类型不兼容等语法错误。

架构兼容性校验：排查目标CPU架构不支持的寄存器、指令类型或寻址方式。

地址偏移校验：排查超出合法范围的内存寻址偏移量、无效的跳转目标等问题。

若校验发现非法指令或格式错误，汇编器会立即终止转换流程并输出明确的错误信息，帮助开发者定位并修正问题。尽管.s文件多由编译器自动生成，但该校验仍能有效规避编译器异常、手动修改.s文件等场景导致的低级错误，确保生成的.o文件是符合架构规范的有效二进制文件。

4.2 在Ubuntu下汇编的命令

gcc -c [输入文件.s] -o [输出文件.o]

图4.2.1 对hello.s进行汇编

由图可知，对hello.s使用命令在当前目录下生成了hello.o。

4.3 可重定位目标elf格式

4.3.1 hello.o的ELF段信息分析

通过readelf -S hello.o的输出可知，hello.o包含14个段，其中核心功能段的属性与作用如下表所示：

|--------------|-------------|------------|------------|------------|---------------------------------------------------------|
| 节头编号 | 段名称 | 类型 | 标志 | 大小 | 功能说明 |
| 1 | .text | PROGBITS | AX | 0xa3 | 存储hello程序的机器码指令，是程序的核心执行代码区域，对应main函数的逻辑实现。 |
| 2 | .rela.text | RELA | I | 0xc0 | .text段的重定位表，记录代码段中需要修正的地址条目（如外部函数调用、只读数据引用），是链接阶段的关键输入。 |
| 5 | .rodata | PROGBITS | A | 0x40 | 存储只读字符串常量，如hello程序中的打印格式字符串、错误提示文本，运行时不可修改。 |
| 11 | .symtab | SYMTAB | - | 0x108 | 符号表，记录hello.o中所有符号的类型、绑定属性与位置，区分 "已定义符号" 与 "未定义符号"。 |
| 12 | .strtab | STRTAB | - | 0x32 | 字符串表，存储符号表中符号对应的文本名称（如main、printf），用于符号的可读性解析。 |

图4.3.1 hello.o的readelf -S输出

4.3.2 hello.o的重定位表分析

readelf -r hello.o的输出显示，.rela.text段包含8个重定位条目，这些条目对应`hello`程序中依赖的外部符号，核心条目解析如下：

|-------------|----------------|--------------|------------|------------------------------------------|
| 偏移量 | 重定位类型 | 符号名称 | 加数 | 功能关联 |
| 0x24 | R_X86_64_PLT32 | puts | -4 | 对应hello程序中错误提示的puts函数调用，需链接时填充puts的实际地址。 |
| 0x2e | R_X86_64_PLT32 | exit | -4 | 对应hello程序中参数错误时的exit函数调用，需链接时绑定exit的地址。 |
| 0x6f | R_X86_64_PLT32 | printf | -4 | 对应hello程序中循环打印的printf函数调用，需链接时从标准库中解析地址。 |
| 0x82 | R_X86_64_PLT32 | atoi | -4 | 对应hello程序中命令行参数转换的atoi函数调用，需链接时填充地址。 |

图4.3.2 hello.o的readelf -s的输出

4.4 Hello.o的结果解析

说明机器语言的构成，与汇编语言的映射关系。特别是机器语言中的操作数与汇编语言不一致，特别是分支转移函数调用等。

4.4.1 反汇编与hello. s 的对照核心结论

通过objdump -d -r hello.o输出与第3章hello.s的逐段对照，二者在程序逻辑、指令序列、功能映射上完全一致，仅存在地址表示形式的差异，具体对应关系如下：

1. 函数入口初始化

图4.4.1 反汇编部分 图4.4.2 hello.s

hello.s:pushq %rbp、movq %rsp, %rbp、subq $32, %rsp

hello.o:55（push %rbp）、48 89 e5（mov %rsp,%rbp）、48 83 ec 20（sub $0x20,%rsp）

指令完全对应，仅subq 32, %rsp在反汇编中以sub 0x20,%rsp呈现，数值一致。

2. 参数校验分支

图4.4.3 反汇编部分 图4.4.4 hello.s

hello.s:cmpl $5, -20(%rbp)、je .L2、call puts@PLT

hello.o:83 7d ec 05（cmpl $0x5,-0x14(%rbp)）、74 19（je 32<main+0x32>）、e8 00000000（callq 28<main+0x28>）

分支判断逻辑一致，puts调用对应重定位标记24: R_X86_64_PLT32 puts-0x4，与hello.s的外部函数调用逻辑匹配。

3. 循环结构

图4.4.5 反汇编部分 图4.4.6 hello.s

hello.s:movl 0, -4(%rbp)、cmpl 9, -4(%rbp)、addl $1, -4(%rbp)

hello.o:c7 45 fc 00000000（movl 0x0,-0x4(%rbp)）、83 7d fc 09（cmpl 0x9,-0x4(%rbp)）、83 45 fc 01（addl $0x1,-0x4(%rbp)）

循环初始化、条件判断、自增操作完全对应，jmp与jle指令的跳转目标偏移量匹配循环逻辑。

1. 函数调用

图4.4.7 反汇编部分 图4.4.8 hello.s

hello.s：call printf@PLT、call atoi@PLT

hello.o：e8 00000000（callq 73<main+0x73>）+6f: R_X86_64_PLT32 printf-0x4、e8 00000000（callq 86<main+0x86>）+82: R_X86_64_PLT32 atoi-0x4

函数调用指令与重定位标记一一对应，hello.s的符号调用在反汇编中体现为 "临时偏移 + 重定位标记" 的形式。

4.4.2 机器语言构成与汇编语言的映射 关系

1. 机器语言的核心构成

机器语言以二进制编码存储，由操作码和操作数两部分组成，对应反汇编中的"十六进制编码"与"助记符+操作数"：

操作码：对应汇编指令的助记符，决定CPU执行的操作类型。例如mov指令的操作码为89（32位操作）或48 89（64位操作），call指令的操作码为e8。

操作数：对应汇编指令的寄存器、内存地址、立即数，以十六进制编码表示。例如%rbp对应55，立即数$5对应05，内存偏移-0x14(%rbp)对应7d ec。

1. 指令的"一一映射"特性

汇编指令与机器语言指令为严格的一一对应关系，无多对一或一对多情况，示例如下：

：单字节操作码，直接对应寄存器压栈操作。

：48标识 64 位操作，89 e5对应mov指令与%rsp→%rbp的寄存器操作数。

：83为操作码，7d ec对应内存偏移-0x14(%rbp)，05对应立即数$5。

：e8为call操作码，00000000为临时偏移，重定位标记补充符号关联信息。

4.4.3 操作数形式差异的关键场景与原因

反汇编中机器语言的操作数与hello.s的汇编操作数存在形式差异，核心集中在分支转移和函数调用场景，本质是"符号化表示"与"数值化编码"的转换，具体如下：

1.分支转移：标签→段内偏移量

hello.s中的形式：使用标签表示跳转目标，例如je .L2。

机器语言中的形式：使用.text段内的绝对偏移量。

差异原因：汇编阶段会将标签转换为段内相对偏移量，机器语言仅识别数值化偏移，无法解析符号标签，因此需完成"标签→偏移"的转换。

2.函数调用：符号名称→临时偏移+重定位标记

hello.s中的形式：使用符号名称表示调用目标，例如call puts@PLT。

机器语言中的形式：使用临时偏移量+重定位标记。

差异原因：汇编阶段无法获取外部函数的实际地址，因此先填充临时偏移，同时在重定位表中记录"符号名称+偏移修正值"，待链接阶段由链接器替换为实际地址。

图4.1完整反汇编代码

4.5 本章小结

本章围绕汇编阶段的 "指令编码与文件组织" 展开，通过gcc -c hello.s -o hello.o命令将汇编文件 hello.s 转换为可重定位目标文件 hello.o。分析表明，汇编器的核心作用包括三方面：一是实现 "汇编指令 - 机器码" 的一一映射，无逻辑优化或语法分析；二是收集符号信息与重定位条目，存入 ELF 文件的符号表与重定位表；三是按 ELF 格式组织.text、.rodata、.data等段，规范内存布局。通过 objdump 反汇编对比 hello.s 与 hello.o，发现二者逻辑完全一致，仅地址表示形式不同。汇编阶段是程序从 "符号化描述" 到 "二进制指令" 的关键一步，生成的 hello.o 虽无法直接运行，但为链接阶段的 "符号解析与地址重定位" 提供了必要的二进制基础。

（第4章1分）

第 5 章 链接

5.1 链接的概念与作用

5.1.1 链接的概念

链接是程序构建流程的最后阶段，特指通过链接器将一个或多个可重定位目标文件与系统库文件合并、解析外部符号依赖、完成地址重定位，最终生成可直接运行的可执行文件的过程。

从hello.o到hello的链接，本质是解决"可重定位目标文件的地址不确定性"与"多文件/库的依赖关联"问题，将分散的代码、数据、符号整合为一个逻辑完整、地址确定的二进制文件。

5.1.2 链接的核心作用

1. 合并可重定位目标文件的段

链接器会将多个可重定位目标文件中功能相同的段进行合并：例如将hello.o的.text段与标准库libc.so的.text段合并，形成可执行文件hello的.text段；将hello.o的.rodata段与库文件的.rodata段合并，统一管理只读数据。

该操作使可执行文件的段结构更规整，符合系统加载时的内存映射规范。

2. 解析外部符号依赖

hello.o中存在未定义的外部符号，链接器会从系统库文件中找到这些符号的定义，并建立关联：例如从libc.so中定位printf函数的实际代码地址，将其与hello.o中call printf的指令地址绑定。

这一过程解决了"符号未定义"的问题，确保程序运行时能正确调用外部函数。

3. 完成地址重定位

链接器会根据hello.o重定位表中的条目，将所有待修正的地址字段替换为可执行文件的实际虚拟地址：例如将hello.o中call printf对应的临时偏移地址，替换为hello中printf函数的实际虚拟地址；同时修正分支转移、数据引用的地址，使所有指令的操作数都指向确定的内存位置。

这是链接的核心作用，使程序从"地址不确定的可重定位文件"转变为"地址确定的可执行文件"。

4. 关联系统库与动态链接器

对于动态链接，链接器会在可执行文件中嵌入动态链接器的路径，并记录动态库的依赖信息：例如在hello中嵌入libc.so的依赖，使程序运行时动态链接器能自动加载libc.so，实现库文件的共享复用。

这一机制既减少了可执行文件的体积，也保证了库文件的版本兼容性。

5.2 在Ubuntu下链接的命令

图5.2.1 对hello.o文件的链接

对文件链接的通用指令为ld -dynamic-linker [动态链接器路径] -o [输出可执行文件名] [C标准库路径] [目标文件]。通过对本虚拟机的路径查询最终形成如图所示的链接指令，并且在运行后在本目录下生成了helllo的执行程序。

5.3 可执行目标文件hello的格式

与可重定位目标文件hello.o相比，hello的 ELF 格式新增了动态链接相关段，如.interp、.dynamic、.plt，且所有段都分配了确定的虚拟地址，这是可执行文件能直接被系统加载到内存运行的核心原因，虚拟地址的确定性使 CPU 能直接从指定地址读取并执行指令。

图5.3.1 hello的各段信息

5.4 hello的虚拟地址空间

图5.1虚拟地址空间信息

5.4.1 虚拟地址空间的核心段映射

|-------------------|------------|------------|-------------------------|---------------------------------------------------|
| 虚拟地址范围 | 大小 | 权限 | 对应 ELF 段（5.3 节） | 功能说明 |
| 0x400000-0x401000 | 0x1000 | r--p | .interp、.note等 | 存储 ELF 头部、动态链接器路径等只读信息，对应 5.3 节的非代码 / 数据段。 |
| 0x401000-0x402000 | 0x1000 | r-xp | .text | 程序代码段，对应 5.3 节.text段的虚拟地址（0x4010d0在此范围内），具备可执行权限。 |
| 0x402000-0x403000 | 0x1000 | r--p | .rodata | 只读数据段，对应 5.3 节.rodata段的虚拟地址（0x402000），存储字符串常量。 |
| 0x404000-0x405000 | 0x1000 | rw-p | .data、.got.plt | 可读写数据段，对应 5.3 节的.data和全局偏移表段，用于存储全局变量、动态链接地址。 |

5.4.2 与ELF段信息的对照分析

1. 地址一致性

虚拟地址空间中hello的段地址，与ELF段的"起始地址"完全匹配，说明系统加载时直接按ELF段的虚拟地址映射到内存。如.text段对应0x401000-0x402000与ELF.text段起始0x4010d0相匹配。

2. 权限匹配性

虚拟地址的权限与ELF段的标志一致，保障了段的访问安全。如.text段为r-xp与ELF.text段标志AX相匹配。

3. 动态库映射：虚拟地址空间中还包含libc.so.6、ld-linux-x86-64.so.2的映射段，这是动态链接的结果。hello运行时会加载依赖的动态库。

5.4.3 虚拟地址空间的特征

hello的虚拟地址空间是系统按ELF格式分配的独立地址区间，各段的地址、权限、大小均与ELF文件的定义严格对应，同时包含动态库、栈、堆等系统默认映射段，保障了程序的独立运行与资源隔离。

5.5 链接的重定位过程分析

图5.5.1 hello的反汇编内容

5.5.1 hello与hello.o的核心差异

1. 重定位条目的变化

hello.o： 反汇编中函数调用、数据引用处附带重定位标记，例如：asm 23: e8 00 00 00 00 callq 28 <main+0x28> 24: R_X86_64_PLT32 puts-0x4 说明puts的地址尚未确定，需链接阶段修正。

hello：反汇编中重定位标记消失，替换为实际虚拟地址，例如：asm 401128: e8 47 ff ff ff callq 401070 <puts@plt> 说明链接阶段已完成puts的地址绑定。

2. 地址的确定性

hello.o中指令的操作数多为临时偏移，如callq 28。

hello中指令的操作数为确定的虚拟地址，如callq 401070。

5.5.2 重定位过程分析

以puts调用为例：

步骤1：hello.o的重定位需求

hello.o的.rela.text段中，puts对应的重定位条目为：

表示.text段偏移0x24处的call指令，需绑定puts的地址，且采用PLT相对寻址。

步骤2：链接阶段的地址绑定

链接器通过以下步骤完成重定位：从C标准库libc.so.6中找到puts的符号定义；在hello的.plt段中为puts分配入口地址；将hello.o中call指令的操作数，修正为puts@plt的虚拟地址。

步骤3：动态链接的延迟绑定

hello中callq 401070 <puts@plt>实际跳转到.plt段的puts入口，运行时由动态链接器完成最终地址绑定：.plt段的入口会触发动态链接器加载libc.so.6中puts的实际地址；将实际地址写入.got.plt段，后续调用直接从.got.plt读取地址，实现"延迟绑定"。

5.6 hello的执行流程

5.6.1 程序加载与初始化阶段

1. 动态链接器入口：_start()

地址：0x00007fffffffe3290

来源：

执行：mov %rsp,%rdi; call _dl_start

2. 动态链接器主函数：_dl_start()

负责加载所有共享库（libc等）、执行重定位

3. C库初始化入口：__libc_start_main_impl()

地址：0x00007ffff7c29dc0

来源：

关键作用：设置程序退出处理；栈保护检查初始化；调用全局构造函数

5.6.2 用户程序执行阶段

1. 用户main函数开始：main()

地址：0x401105

来源：

参数检查：比较argc是否等于5，cmpl $0x5,-0x14(%rbp)

若不等于5：打印错误信息并调用exit(1)

2. 循环处理逻辑：

printf格式化输出：打印学号、姓名、电话

atoi转换：将第5个参数转为整数

sleep休眠：执行10次循环，每次休眠指定秒数

循环控制：for(i=0; i<10; i++)

3. 等待用户输入：getchar()

地址：0x40119c处的call 0x401090 <getchar@plt>

来源：

5.6.3 输入处理阶段

1. getchar系统调用链：

getchar@plt → _IO_getc → _IO_new_file_underflow

最终调用read系统调用0x7ffff7d14852

2. 文件I/O处理：_IO_new_file_underflow()

地址：0x7ffff7c8cc39

负责从标准输入读取数据

5.6.4 程序终止阶段

1. main函数返回：

mov $0x0,%eax，设置返回值为0

leave; ret

2. 返回C库清理：

返回到`__libc_start_main_impl`中main调用后的代码

执行程序退出前的清理工作

3. 程序最终退出：

调用exit()系统调用

进程终止，资源释放

图5.6.1 main函数的完整反汇编

5.7 Hello的动态链接分析

5.7.1 静态分析

1. 程序依赖库分析

图5.7.1 链接库展示

linux-vdso.so.1：虚拟动态共享对象，加速系统调用

libc.so.6：C标准库，包含printf、puts等函数

ld-linux-x86-64.so.2：动态链接器

2. 动态段信息

图5.7.2 动态段展示

PLTGOT地址：0x404000（全局偏移表起始地址）

JMPREL地址：0x400528（过程链接表重定位项）

STRTAB地址：0x400478（字符串表）

SYMTAB地址：0x4003b8（符号表）

5.7.2 PLT/GOT 结构分析

PLT表布局及分析

图5.7.3 PLT表

以puts@plt为例：

图5.7.4 put@plt信息

PLT结构解析：

1. endbr64：控制流强制指令

2. 跳转指令：通过%rip相对寻址跳转到GOT条目

3. 计算目标地址：0x401074 + 4 + 0x2f9d = 0x404018

5.7.3 动态链接过程 分析

1. 初始状态分析

图5.7.5 初始状态信息

GOT条目指向0x401010，这是延迟绑定解析器

程序尚未调用puts，未进行动态链接解析

2. 触发动态链接分析

执行错误参数以触发puts：

图5.7.6 puts触发

调用前：0x404018 -> 0x0000000000401010

调用后：0x404018 -> 0x00007ffff7c8d5d0

第一次调用过程：程序调用 puts@plt (0x401070)，PLT跳转到 GOT[puts] (0x404018)，GOT当前指向解析器 (0x401010)

解析器执行：通过动态符号表查找"puts"，在libc中获取puts的真实地址，更新GOT[puts]为真实地址，跳转到真实的puts函数，后续调用直接通过GOT跳转到libc。

5.8 本章小结

本章系统阐述链接阶段的 "整合与地址绑定" 功能，通过ld -dynamic-linker /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 -o hello /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/libc.so.6 hello.o命令，将 hello.o 与 C 标准库整合为可执行文件 hello。核心过程包括：合并功能相同的段、解析外部符号依赖、完成地址重定位。ELF 格式分析显示，hello 新增.interp、.plt等段，所有段分配固定虚拟地址，支持系统直接加载。动态链接分析表明，程序运行时通过 PLT/GOT 延迟绑定机制，首次调用函数时由动态链接器解析地址，后续直接复用 GOT 中的地址，平衡 "可执行文件体积" 与 "运行效率"。本章实验揭示了 "为什么目标文件无法运行而可执行文件可以" 的本质，也为理解进程加载时的内存映射提供了文件层面的依据。

（第5章1分）

第 6 章 hello进程管理

6.1 进程的概念与作用

6.1.1 进程的概念

进程是计算机系统中正在运行的程序的实例，是操作系统进行资源分配和调度的基本单位。从结构上看，进程由程序代码、数据、进程控制块、寄存器上下文、栈空间等组成。其中，PCB是进程存在的唯一标识，包含进程ID、进程状态、优先级、程序计数器、内存指针、打开文件描述符等核心信息，操作系统通过PCB对进程进行全生命周期的管理。

对于hello程序而言，当用户执行./hello命令时，操作系统会为其创建一个专属进程，将hello的可执行文件加载到内存，分配独立的虚拟地址空间、CPU时间片、I/O资源等，此时hello不再是磁盘上的静态文件，而是具备独立运行能力的动态进程。

6.1.2 进程的作用

1. 资源隔离

进程拥有独立的虚拟地址空间，不同进程的内存访问相互隔离，避免了一个进程的错误操作影响其他进程的运行，保障了系统的稳定性。例如进程的代码段、数据段与其他进程的内存区域完全分离，不会因其他进程的内存越界而被破坏。

2. 调度与并发

操作系统通过进程调度算法，使多个进程分时共享CPU资源，实现宏观上的并发执行。即使CPU是单核，用户也能同时运行程序、文本编辑器等多个应用，提升了CPU的利用率。

3. 资源分配载体

操作系统的各类资源均以进程为单位分配。进程运行时，操作系统会为其分配必要的内存空间存储代码和数据，分配文件描述符用于标准输入输出，确保程序能够正常访问各类资源。

4. 程序执行的动态载体

静态的程序文件无法直接运行，只有通过创建进程，将程序加载到内存并赋予运行所需的资源，才能使程序的指令被CPU执行，实现程序的功能。程序的"打印输出、休眠、等待输入"等逻辑，均依赖进程的动态执行过程。

6.2 简述壳Shell-bash的作用与处理流程

6.2.1 Shell-bash的作用

Shell是用户与操作系统内核之间的命令行交互中介，本质是一个运行在用户态的特殊进程，核心作用包括：

1. 命令解释与执行

接收用户输入的命令，解析语法后调用内核的系统调用完成功能。

2. 环境管理

维护用户的环境变量，为执行的程序提供统一的运行环境。

3. 作业控制

支持进程的前台、后台调度，可管理多个并行任务。

4. 脚本自动化

通过shell脚本实现重复性操作的自动化执行。

5. 输入输出重定向、管道

支持将命令的输入输出重定向到文件，或通过管道连接多个命令的数据流。 6.2.2 Shell-bash的处理流程

以执行./hello 2024113013 王新桐 10000000000 2为例

命令读取：bash 通过标准输入读取用户输入的命令字符串，存储在缓冲区中。

词法分析：将命令字符串拆分为令牌，此处拆分为./hello、2024113013、王新桐、10000000000、2。

语法分析：判断命令类型，./hello为可执行文件路径，后续为命令参数，无语法错误。

路径查找：由于命令以./开头，bash 直接将其解析为当前目录下的可执行文件，无需通过 PATH 环境变量查找。

创建子进程：bash 通过fork系统调用创建一个新的子进程，子进程复制 bash 的 PCB、内存空间等资源，成为 bash 的子进程。

加载执行程序：子进程通过execve系统调用，将当前进程的代码段、数据段替换为hello可执行文件的内容，加载hello的代码、数据到内存，初始化进程的虚拟地址空间，开始执行hello的_start函数。

等待子进程结束：bash 父进程调用waitpid系统调用，进入阻塞状态，等待 hello 子进程执行完成。

回收资源与返回状态：hello 子进程执行完毕后，操作系统回收其资源，通过exit系统调用返回退出状态码。bash 父进程被唤醒，读取子进程的退出状态码，更新自身状态，随后返回命令行提示符，等待用户输入下一条命令。

6.3 Hello的fork进程创建过程

以终端中执行./hello 2024113013 wxt 1000000000 2为例

图6.1.1 hello程序的fork，execve追踪

1. Shell发起fork调用

当用户在Shell中输入./hello命令并回车后，Shell进程先完成命令的解析，确认./hello为有效可执行文件后，调用fork()系统调用，触发从用户态到内核态的切换，请求内核创建新的子进程：

内核为新进程分配唯一PID，如图中显示的2719；

内核为新进程创建独立的进程控制块，并复制父进程PCB中的大部分信息，仅修改PID、父进程ID等关键字段；

通过写时复制机制，子进程不直接复制父进程的完整地址空间，而是与父进程共享这些内存资源，并将共享内存页的权限设置为只读；

仅当后续父进程或子进程对共享内存执行写操作时，内核才会为修改的内存页分配新的物理内存，并复制该页的内容，实现父子进程的内存隔离；

子进程的父进程ID被设置为Shell的PID，如图中2719对应的PPID为2713；

内核复制父进程的寄存器上下文，使子进程的执行上下文与父进程完全一致，确保子进程从fork()调用的返回点继续执行。

2. fork调用返回与进程分流

内核完成子进程的创建后，fork()系统调用会产生两次返回，实现父子进程的分流：Shell：fork()调用返回子进程的PID 2719，随后Shell不会立即执行后续逻辑，而是进入阻塞状态，通过waitpid()或wait()系统调用等待子进程执行完成。

新子进程：fork()调用返回0，此时子进程仍处于Shell进程的代码上下文和内存空间中，未加载Hello程序，本质还是一个"克隆版"的Shell子进程。

3. 进程分流与程序加载

新子进程：接收到fork()返回的0后，会立即调用execve()系统调用，如图中strace日志显示的execve("./hello", ["./hello", "2024113013", "wxt", "1000000000", "2"], 0x5fdb9a7bfd0 /* 59 vars */) = 0，该调用会释放子进程当前共享的Shell内存资源，将自身的代码段、数据段、堆、栈等地址空间替换为hello程序的内容，完成从"Shell子进程"到"Hello进程"的转换，随后开始执行Hello程序的入口指令。

6.4 Hello的execve过程

以./hello 2024113013 wxt 1000000000 2的执行为例

1. 调用触发

Shell通过fork创建的子进程PID 2719，在fork返回0后，立即发起execve系统调用，请求加载hello程序。

2. 参数传递与合法性校验

子进程向内核传递3个核心参数

目标程序路径：./hello；

命令行参数数组：["./hello", "2024113013", "wxt", "1000000000", "2"]；

环境变量数组：继承自Shell的59个环境变量。

内核校验：检查./hello是否为合法的ELF可执行文件、是否拥有执行权限。

3. 旧资源释放

内核释放子进程当前的内存资源，清空原进程的地址空间，为加载hello程序做准备。

4. 目标程序加载

内核解析hello的ELF文件头部，获取代码段、数据段等的位置与大小；为hello的各段分配虚拟地址空间，并建立虚拟地址到物理内存的映射；将hello的代码、数据从磁盘读取到对应的虚拟地址空间。

5. 执行流切换

内核将进程的程序计数器设置为hello的入口地址，进程开始执行hello的代码。

由图中终端输出可直接观测execve的执行痕迹：

strace日志：[pid 2719] execve("./hello", ["./hello", "2024113013", "wxt", "1000000000", "2"], 0xazc7s55f4d0 /* 59 vars */) = 0，明确记录了execve的调用参数与成功返回；

进程状态：ps -ef | grep hello显示PID 2719的进程名为./hello，说明execve已完成程序替换；

信号关联：当hello进程被SIGINT终止时，Shell收到SIGCHLD信号，体现execve后子进程仍与Shell保持父子关系。

6.5 Hello的进程执行

6.5.1 Hello进程的调度过程

以Hello程序循环打印"Hello 2024113013 wxt 1000000000 2"为例，调度流程如下：

1. 就绪态→运行态

Hello进程完成execve加载后，进入就绪态。操作系统的调度器根据CFS算法，为Hello分配时间片，将其上下文加载到CPU，Hello进入运行态，开始执行打印逻辑。

2. 运行态→就绪态

当Hello的时间片耗尽时，CPU触发时钟中断：

内核保存Hello的当前上下文到进程控制块；

调度器选择下一个就绪进程，加载其上下文到CPU，该进程进入运行态；

Hello进程回到就绪态，等待下一次调度。

3.运行态→阻塞态

若Hello执行sleep，会主动调用nanosleep系统调用：

内核将Hello的状态改为阻塞态，移出就绪队列；

调度器调度其他就绪进程执行；

当休眠时间结束，内核将Hello重新加入就绪队列，等待调度。

6.5.2 用户态与核心态的转换

Hello进程的执行过程中，存在多次用户态与核心态的切换，典型场景包括：

1. 用户态→核心态

触发条件：执行系统调用、触发异常；

转换过程：CPU执行syscall指令，保存用户态上下文，切换到核心态，执行内核对应的系统调用处理函数。

2. 核心态→用户态

触发条件：系统调用执行完成、异常处理完毕；

转换过程：内核恢复Hello的用户态上下文，执行iret指令，切换回用户态，Hello继续执行用户空间的代码。

6.6 hello的异常与信号处理

6.6.1 Hello进程的异常类型

异常是Hello进程执行自身代码时触发的错误，内核会捕获异常并发送对应信号，常见异常如下：

1. 内存访问异常

Hello程序中数组越界、访问空指针、对只读内存执行写操作。

对应信号：SIGSEGV。

内核逻辑：内存管理单元检测到非法内存访问，触发异常后向Hello发送SIGSEGV，默认终止进程并生成核心转储文件。

2. 算术运算异常

Hello程序中除以零、浮点运算溢出。

对应信号：SIGFPE。

内核逻辑：CPU算术逻辑单元执行非法运算后触发异常，内核发送SIGFPE信号，执行默认终止操作。

3. 非法指令异常

Hello程序包含CPU不支持的指令、指令格式错误。

对应信号：SIGILL。

内核逻辑：CPU指令解码器无法识别当前指令，触发异常后发送SIGILL信号，默认终止进程并生成核心转储文件。

4. 资源耗尽异常

Hello程序无限申请堆内存、打开文件数量超出系统限制。

对应信号：SIGBUS、SIGXFSZ。

6.6.2 Hello进程的信号类型

信号是内核或其他进程向Hello进程发送的通知，用于控制进程状态或告知事件，常见信号如下：

1. 用户主动干预类信号

SIGINT：用户按下Ctrl+C触发，默认行为是终止Hello进程。

图6.6.1 进程中Ctrl+C

SIGTSTP：用户按下Ctrl+Z触发，默认行为是暂停Hello进程。

图6.6.2 进程中Ctrl+Z

SIGCONT：执行fg命令时触发，用于恢复暂停的Hello进程，从停止态转为运行态。

图6.6.3 fg命令

2. 进程管理类信号

SIGTERM：执行kill <PID>时默认发送，属于"优雅终止"信号，允许Hello进程执行清理操作后退出。

图6.6.4 kill命令

SIGKILL：执行kill -9 <PID>时发送，属于"强制终止"信号，无法被Hello进程忽略或捕获，直接终止进程。

图6.6.5 kill -9 命令

6.6.3 信号处理实操与结果分析

1. Ctrl+Z触发SIGTSTP：暂停进程

图6.6.2中终端显示[1]+ 已停止 ./hello 2024113013 wxt 1000000000 2，Hello进入停止态，释放CPU资源。

验证：执行ps/jobs命令，可看到Hello进程仍存在，状态为"已停止"。

图6.6.6 ps命令

图6.6.7 jobs命令

2. fg触发SIGCONT：恢复进程运行

由图6.6.3知Hello进程从停止态恢复为运行态，继续循环打印输出。

说明：SIGCONT是唯一能恢复暂停进程的信号，与SIGTSTP配合实现进程前后台调度。

3. kill -9触发SIGKILL：强制终止

由图6.6.5可知终端显示[1]+ 已杀死 ./hello 2024113013 wxt 1000000000 2，Hello进程被强制终止，资源被内核回收。

验证：再次执行ps，无Hello进程残留。

4. pstree验证：进程父子关系不变

图6.6.8 pstree命令

图

显示bash(<Shell PID>)───hello(<Hello PID>)的层级关系

说明：信号处理仅改变Hello进程状态，不改变其与Shell的父子关系。

5.用户主动干预类

终端输入混乱：乱按键盘不会触发信号，仅会作为标准输入传递给进程，若进程未处理，输入会被暂存。

图6.6.8 乱按键盘输出

6.6.4 Hello 进程的异常与信号处理机制

1. 默认处理

异常对应信号SIGSEGV、SIGFPE、SIGILL：默认行为是终止进程并生成核心转储文件。

用户干预、管理信号SIGINT、SIGTSTP、SIGKILL：默认行为为终止或暂停进程，保障用户对进程的可控性。

2. 自定义捕获

可捕获信号：SIGSEGV、SIGINT、SIGTERM等，可通过signal/sigaction函数注册自定义处理函数。

不可捕获信号：SIGKILL（9）、SIGSTOP（19），无法被忽略或捕获，确保系统能强制管理失控进程。

3. 异常调试方法

开启核心转储：ulimit -c unlimited。

生成核心文件：运行异常 Hello 程序，自动生成core文件。

定位异常点：gdb ./hello core，gdb 会直接提示异常发生的代码行。

6.7本章小结

本章以 hello 进程的"创建 - 执行 - 终止"为主线，剖析 Linux 进程管理机制。Shell 通过 fork 创建子进程时，采用写时复制策略，仅复制页表而非物理内存，降低创建开销；子进程通过 execve 完全替换虚拟内存空间，加载 hello 程序的代码与数据，实现"Shell 子进程→hello 进程"的转换。进程执行阶段，CPU 调度器通过 CFS 算法分配时间片，使 hello 在就绪态、运行态、阻塞态间切换；用户态与内核态的转换通过系统调用触发，保障资源访问的安全性。异常与信号处理实验表明，SIGINT终止进程、SIGTSTP暂停进程、SIGCONT恢复进程，而 SIGKILL不可捕获，确保系统能强制回收失控进程。本章不仅验证了进程作为 "资源分配与调度基本单位" 的核心作用，更通过 strace/ps/pstree 等工具的实操，直观呈现了操作系统如何通过 PCB、信号、调度算法管理进程全生命周期。

（第6章 2 分）

第 7 章 hello的存储管理

7.1 hello的存储器地址空间

7.1.1 逻辑地址

概念：hello程序源码编译后，指令、变量等在可执行文件中对应的地址，是程序开发者直接接触的地址形式。

hello中的体现： 例如hello的main函数在编译后的可执行文件中，对应的逻辑地址是0x0000000000401118；程序中定义的全局变量g_name，逻辑地址可能是0x0000000000404020。

特点：仅在程序内部有效，不直接对应物理内存位置，需经过地址转换才能访问实际内存。

7.1.2 线性地址

概念：x86架构中，逻辑地址经过分段机制转换后的地址，由段选择符+段内偏移组成，是虚拟地址空间中的连续地址。

hello中的体现：Linux默认将所有段的基地址设为0，因此hello的逻辑地址，如0x401118会直接作为线性地址，无需额外分段转换。

作用：实现不同进程模块的地址隔离，现代系统中主要作为虚拟地址的中间形式。

7.1.3 虚拟地址

概念：hello进程运行时，CPU指令中使用的地址，是进程"看到"的独立地址空间，通常为0x0000000000000000到0xFFFFFFFFFFFFFFFF的64位空间。

hello中的体现：当hello进程被加载后，其代码段、数据段会被映射到虚拟地址空间的特定区域，如代码段在0x400000附近，堆在0x550000附近；程序中执行printf时，指令中使用的printf函数地址，如0x7ffff7e2a7c0就是虚拟地址。

特点：每个进程拥有独立的虚拟地址空间，hello的虚拟地址与其他进程的虚拟地址互不干扰；虚拟地址不直接对应物理内存，需通过"页表机制"转换为物理地址。

7.1.4 物理地址

概念：计算机物理内存的实际地址，是CPU通过内存总线访问内存的最终地址。

hello中的体现：hello进程的虚拟地址，如0x401118会被CPU的内存管理单元通过页表转换为物理地址，如0x12345000，最终访问该物理地址对应的内存单元，读取main函数的指令。

特点：物理地址是全局唯一的，所有进程共享物理内存；进程无法直接操作物理地址，只能通过虚拟地址间接访问。

7.2 Intel逻辑地址到线性地址的变换-段式管理

段式管理是 Intel x86 架构中 "逻辑地址→线性地址" 的核心转换机制，其本质是通过段选择符 + 段内偏移的组合，实现地址空间的隔离与扩展。

7 .2.1 逻辑地址的结 构

Intel架构中，逻辑地址由两部分组成：

段选择符：用于定位对应的段描述符。

段内偏移：逻辑地址在目标段内的相对地址。

7.2.2 段描述符与段描述符表

段描述符是段的"属性配置文件"，存储在全局描述符表或局部描述符表中，包含以下关键信息：

段基地址：段在线性地址空间中的起始地址；段限长：段的最大长度；段属性：如读写权限、段类型等。

7****.2.3 逻辑地址→线性地址的转换流程****

以hello进程的逻辑地址0x08:0x00401118为例，转换步骤如下：

1. 解析段选择符

段选择符0x08的高13位用于索引GDT中的段描述符，低3位用于指定特权级和描述符表类型。

2. 获取段描述符

从GDT中读取第1项，得到段基地址0x00000000、段限长0xFFFFFFFF。

3. 验证段内偏移

检查段内偏移0x00401118是否小于段限长0xFFFFFFFF。

4. 计算线性地址

线性地址 = 段基地址 + 段内偏移，即0x00000000 + 0x00401118 = 0x00401118。

7.2.4 Linux 下的 "平坦分段" 机制

现代 Linux 系统为简化管理，采用平坦分段模式：将所有段的基地址设为0，段限长设为最大线性地址；逻辑地址的段内偏移直接等价于线性地址。

7.3 Hello的线性地址到物理地址的变换-页式管理

图7.1 hello虚拟页→物理页映射

7.3.1 页式管理的核心概念

页式管理将hello的线性地址划分为4KB大小虚拟页，通过页表映射到物理内存的页框。截图中pmap -x的输出展示了hello进程的虚拟地址、页大小、内存权限等信息。

7.3.2 线性地址的分页结构

以图中hello的代码段地址0000000000400000为例，64位架构下其分页结构为：

页全局目录索引（PGD）：高9位0000000000400000的高9位为0x000；

页上级目录索引（PUD）：次高9位0x000；

页中间目录索引（PMD）：中间9位0x020；

页表索引（PT）：次低9位0x000；

页内偏移：低12位0x000。

7.3.3 线性地址→物理地址的转换流程

以截图中hello的线性地址0000000000401000为例，转换步骤如下：

1. 定位页表：CPU通过CR3寄存器读取hello进程的页全局目录基地址，依次通过PGD、PUD、PMD索引，找到对应的页表。

2. 查找页表项： 用页表索引在页表中找到对应的页表项，该页表项存储了物理页框的基地址。

3. 计算物理地址： 物理地址 = 物理页框基地址 + 页内偏移，即0x12346000 + 0x000 = 0x12346000。

7.3.4 页式管理体现

图中pmap -x的输出对应hello进程的页映射信息，核心字段解析： 地址：hello的线性地址，如0000000000400000对应代码段的虚拟页；

Kbytes：虚拟页的大小，均为4KB，符合页式管理的页大小定义；

RSS：该虚拟页实际占用的物理内存大小，如0000000000400000的RSS为4，说明该虚拟页已加载到物理内存；

Mode：页的权限，如r----表示只读，对应代码段；rw---表示读写，对应数据段；

Mapping：页的来源，如hello对应程序自身的代码、数据段，libc.so.6对应动态库，[stack]对应栈空间。

7.3.5 页式管理的特性

1. 内存隔离： 截图中hello的线性地址，如0000000000400000与其他进程的线性地址互不干扰，页表的独立性保障了进程间的内存隔离。

2. 写时复制： 若hello进程通过fork创建子进程，子进程会共享hello的物理页框；仅当子进程修改内存时，才会分配新的物理页框。

3. 按需加载： 截图中libc.so.6的部分虚拟页，如0007abbe2415000的RSS为0，说明这些虚拟页尚未加载到物理内存，需访问时触发缺页异常后再加载。

7.4 TLB与四级页表支持下的VA到PA的变换

虚拟地址到物理地址的变换中，四级页表负责地址的层级映射，而TLB是加速映射的硬件缓存，二者结合实现高效的地址转换。

7.4.1 核心概念

TLB的作用 TLB是CPU内部的高速缓存，用于存储近期访问过的虚拟页→物理页框的映射关系。由于四级页表的层级查询耗时较长，TLB通过缓存热点映射，将地址转换的时间从"内存访问级"缩短到"CPU缓存级"。

7.4.2 四级页表的结构

64位Intel架构的四级页表包含：

1. 页全局目录（PGD）：最高层级的页表，由CR3寄存器指向；

2. 页上级目录（PUD）：PGD的下一级页表；

3. 页中间目录（PMD）：PUD的下一级页表；

4. 页表（PT）：最底层页表，存储虚拟页到物理页框的直接映射。

以hello进程的虚拟地址0x0000555555554118为例，其四级页表索引为：PGD 0x000 → PUD 0x2A → PMD 0x55 → PT 0x41。

7.4.3 TLB+四级页表的VA→PA变换流程

1. TLB查询： CPU先将虚拟地址的"虚拟页号"作为键，查询TLB中是否存在对应的物理页框映射。

若命中：直接从TLB中获取物理页框基地址，结合页内偏移得到物理地址，完成转换。

若未命中：进入四级页表查询流程。

2. 四级页表查询：

通过CR3寄存器读取hello的PGD基地址，用PGD索引找到PUD表基地址；用PUD索引找到PMD表基地址；用PMD索引找到PT表基地址；用PT索引找到物理页框基地址。

3. TLB更新与物理地址计算

将"虚拟页号→物理页框基地址"的映射写入TLB，再通过"物理页框基地址+页内偏移"得到物理地址。

7.5 三级Cache支持下的物理内存访问

7.5.1 三级Cache的层级结构

三级Cache是CPU与物理内存之间的多级缓存层次：

L1 Cache：集成在CPU核心内，分为指令Cache和数据Cache，容量最小，通常几KB~几十KB、速度最快，延迟仅1~3个CPU时钟周期。

L2 Cache：通常每个CPU核心独占，容量中等，几十KB~几MB，速度略低于L1，延迟约10~20个时钟周期。

L3 Cache：多核心共享，容量最大，几MB~上百MB，速度最慢，但远快于物理内存。

7.5.2 物理内存访问的具体流程

L1d 查找：

CPU 计算地址的 "Cache 索引"，检查 L1d 的标签是否匹配该地址；

若命中：直接从 L1d 读取数据。

L1d 未命中→L2 查找：

核心 1 向自身独占的 L2 发送请求，L2 同样通过 "索引 + 标签" 匹配地址；

若 L2 命中：L2 将数据写入 L1d，同时更新 L1d 的标签，CPU 从 L1d 读取。

L2 未命中→L3 查找：

核心 1 向共享 L3 发送请求，L3 通过目录定位数据；

若 L3 命中：L3 将数据先写入核心 1 的 L2，再写入 L1d，CPU 读取。

L3 未命中→物理内存访问：

L3 向内存控制器发起 "读请求"，内存控制器通过 DDR5 总线从物理内存读取数据；

数据先写入 L3，再依次写入核心 1 的 L2、L1d，最终 CPU 读取。

7.5.3 三级 Cache 的替换策略

Cache 容量有限，新数据写入时需替换旧数据，三级 Cache 的策略各有侧重：

L1d/L2：采用2 路 / 4 路组相联 + 伪 LRU

例：L1d 是 8 路组相联，每个组有 8 个 Cache 行；当组内已满时，PLRU 通过 "树状位记录" 快速选出 "最近最少使用" 的行替换，避免全组遍历。

L3：采用16 路组相联 + 真 LRU

L3 容量大、延迟容忍度高，真 LRU 会记录每个 Cache 行的 "访问时间戳"，精确替换最久未用的行，提升命中率。

7.6 hello进程fork时的内存映射

7.6.1 fork前hello进程的内存映射结构

|---------------|------------------|------------------|
| 虚拟内存段 | 构建方式 | 物理内存映射逻辑 |
| 代码段（.text） | 映射可执行文件的代码段区域 | 只读，与同程序进程共享物理页 |
| 数据段（.data） | 映射可执行文件的已初始化数据 | 私有，初始映射物理页（写时复制） |
| BSS 段 | 分配零初始化数据区域 | 私有，按需分配物理页 |
| 堆 | 初始化动态内存分配区域 | 私有，可扩展物理页 |
| 栈 | 分配新的用户栈空间 | 私有，初始分配小物理页 |
| 共享库段 | 加载依赖的系统库（如 libc） | 共享物理页 |
| 环境变量 / 参数段 | 存储argv和envp数据 | 私有，映射物理页 |

7.6.2 fork时的内存映射复制逻辑

当hello进程调用fork()创建子进程时，内核会执行写时复制（的内存映射策略：

1. 页表复制：内核为子进程创建独立的页表，直接复制父进程的页表项，但将所有页表项的权限标记为"只读"。

2. 物理页共享：子进程的虚拟内存段与父进程对应段共享同一物理页，包括代码段、数据段、堆、栈等，不立即复制物理内存内容。

3. 写操作触发复制：若父、子进程对某共享物理页执行写操作，CPU会触发"写保护异常"，内核此时才会为该页分配新的物理页，复制原页内容后修改页表权限为"可写"，实现物理页的私有化。

7.6.3 fork后hello父 、 子进程的内存映射差异

fork完成后，父、子进程的内存映射呈现以下差异：

代码段：始终共享物理页，因代码段只读，不会触发写操作。

数据段、堆、栈：未写的页保持共享，已写的页各自拥有独立物理页。

进程控制块：父、子进程的PCB是独立的物理内存区域，分别记录各自的内存映射状态。

7.6.4 对hello进程的影响

内存开销：fork时仅复制页表，避免了物理内存的立即拷贝，降低了hello进程创建子进程的内存成本。

执行逻辑：子进程继承hello进程的内存状态，但后续写操作不会影响父进程，保证了进程独立性。

7.7 hello进程execve时的内存映射

7.7.1 execve的核心作用

当hello进程调用execve执行新程序时，内核会完全替换当前进程的虚拟内存空间------原hello进程的所有内存段都会被清空，进程将以新程序的内存结构继续运行，仅保留PID、文件描述符等非内存资源。

7.7.2 内存映射的重建流程

1. 原内存的清理

内核首先释放hello进程原有的虚拟内存映射关系：解除原内存段与物理页的绑定，若这些物理页没有被其他进程共享，则直接回收；同时销毁原进程的页表，为新程序的内存结构做准备。

2. 新程序的内存段构建

内核解析新程序的可执行文件，逐段构建新的虚拟内存映射：

代码段：直接映射可执行文件中的代码区域，这部分内存是只读的，会与系统中其他运行同程序的进程共享物理页，以节省内存资源。

数据段与BSS段：数据段对应可执行文件中已初始化的全局/静态变量，内核会先通过写时复制的方式映射物理页；BSS段则是零初始化的变量区域，内核会分配新的虚拟空间，按需绑定物理页。

堆与栈：堆被初始化为动态内存分配的起始区域，可后续扩展；栈则是全新的用户栈空间，初始分配较小的物理页，满足函数调用的基础需求。

共享库与参数：内核会加载新程序依赖的共享库，并为这些库建立共享的物理页映射；同时会在内存中开辟区域，存储新程序的运行参数与环境变量。

7.7.3 与fork内存映射的差异

fork后的内存映射是继承自父进程hello的，与父进程共享未修改的物理页，仅在写操作时才会独立分配物理页；而execve后的内存映射则是完全重建的------既不继承原hello进程的任何内存段，也不会与原进程共享物理页，是完全独立的新内存空间。

7.7.4 对hello进程的影响

原hello进程的代码、数据等内存内容会被彻底替换，进程的执行流会直接跳转到新程序的入口函数；新程序的运行与原hello进程的内存状态无任何关联，仅复用原进程的标识与系统资源。

7.8 缺页故障与缺页中断处理

7.8.1 缺页故障的产生

当进程访问某虚拟地址时，若该地址对应的页表项未建立或页表项标记为"未映射"，CPU会判定为缺页故障。

这是一种合法的内存访问异常，并非错误，通常因"虚拟内存未分配物理页""数据被换出到磁盘"等场景触发。

7.8.2 缺页中断的处理流程

缺页故障会触发CPU的缺页中断，内核通过以下步骤处理：

1. 中断响应：CPU暂停当前进程的执行，切换到内核态，保存进程上下文。

2. 地址合法性检查：内核验证触发缺页的虚拟地址是否属于进程的合法虚拟内存空间。若地址非法，直接终止进程。

3. 分配物理页：若地址合法，内核从物理内存中分配一个空闲页，或从交换分区中读取对应数据到物理页。

4. 更新页表：将新分配的物理页地址写入进程的页表项，并标记页表项为"已映射""可读写"等权限。

5. 恢复进程：内核恢复进程的上下文，切换回用户态，让进程重新执行触发缺页的指令，此时该地址已映射到物理页，访问可正常完成。

7.8.3 缺页中断的常见场景

首次访问：进程的虚拟内存首次被访问时，内核尚未分配物理页，触发缺页中断以建立映射。

交换分区换入：当物理内存不足时，内核会将部分进程的物理页数据写入交换分区；当进程再次访问这些数据时，会触发缺页中断，将数据从交换分区读回物理页。

写时复制：fork后的进程共享父进程的物理页，当进程执行写操作时，会触发缺页中断，内核为其分配新的物理页并复制数据。

7.9本章小结

本章全面解析 hello 进程的存储管理机制，覆盖"地址转换 - 缓存加速 - 内存映射 - 异常处理"全链路。地址转换方面，Linux 采用"平坦分段 + 四级页表" 模式，逻辑地址直接作为线性地址，通过页表与 TLB将虚拟地址转换为物理地址，TLB 缓存热点映射，将转换延迟从"内存级"降至"CPU缓存级"。三级 Cache通过分层设计优化物理内存访问：L1/L2 为核心独占，采用伪 LRU 替换策略保障低延迟；L3 为多核心共享，采用真 LRU 提升命中率。进程操作的内存映射差异显著：fork 通过写时复制共享物理页，仅写操作触发复制；execve 完全重建虚拟内存，仅保留 PID 等非内存资源。缺页中断作为虚拟内存的核心机制，通过"地址合法性检查 - 物理页分配 - 页表更新"流程，支撑首次访问、交换分区换入、写时复制等场景，避免物理内存浪费，但频繁缺页会引发内存颠簸。本章实验通过 pmap/readelf 等工具，验证了虚拟地址空间的段布局、页表映射与 Cache 加速效果，揭示了存储管理"高效复用物理内存""降低访问延迟"的设计目标。

（第7章 2分）

第 8 章 hello的IO管理

8.1 Linux的IO设备管理方法

8.1.1 设备的模型化

Linux将所有I/O设备抽象为文件，通过统一的文件接口屏蔽设备差异：每个设备对应一个设备文件，存储于/dev目录下，如硬盘对应/dev/sda、串口对应/dev/ttyS0；设备的操作，如读、写、控制被映射为文件操作，无需区分设备类型，仅通过文件描述符即可访问。

8.1.2 设备管理的核心

UNIX I/O接口 Linux复用UNIX标准I/O接口实现设备管理，核心接口包括：

1. 打开设备：通过open()函数打开设备文件，获取唯一的文件描述符，标识对该设备的访问。

2. 读写设备：通过read() write() 函数与设备交互，数据以字节流形式传输。

3. 控制设备：通过ioctl()函数实现设备的特殊控制。

4. 关闭设备：通过close()函数释放设备文件描述符，结束对设备的访问。

8.1.3 设备的分类与驱动支撑

Linux的I/O设备分为两类，由对应的驱动程序实现文件接口的底层逻辑：

字符设备：以字节流为单位顺序访问，驱动需实现字符读写、设备控制等逻辑。

块设备：以固定大小的数据块为单位随机访问，驱动需实现块读写、缓存管理等逻辑。

8.2 简述Unix IO接口及其函数

Unix I/O接口是一套统一的文件、设备操作标准，核心思想是"一切皆文件"，通过通用函数屏蔽文件、设备、管道等资源的差异，主要包含以下核心函数：

1. 打开资源：open()

功能：打开文件、设备文件或创建新文件，建立进程与资源的关联。

关键参数：资源路径、打开模式。

返回值：成功时返回文件描述符；失败返回-1。

2. 读取数据：read()

功能：从已打开的资源中读取数据到内存缓冲区。

关键参数：文件描述符、目标缓冲区地址、读取字节数。

返回值：成功时返回实际读取的字节数；返回0表示已到资源末尾；失败返回-1。

3. 写入数据：write()

功能：将内存缓冲区的数据写入已打开的资源。

关键参数：文件描述符、源缓冲区地址、写入字节数。

返回值：成功时返回实际写入的字节数；失败返回-1。

4. 控制资源：ioctl()

功能：实现资源的特殊控制操作，是针对非读写操作的扩展接口。

关键参数：文件描述符、控制命令、命令参数。

返回值：成功返回0；失败返回-1。

5. 关闭资源：close()

功能：关闭已打开的资源，释放进程与资源的关联，回收文件描述符。

关键参数：文件描述符。

返回值：成功返回0；失败返回-1。

8.3 printf的实现分析

8.3.1 核心执行流程

printf的实现是用户态格式化→系统调用→内核驱动→硬件显示的分层过程：

格式化字符串生成：printf调用vsprintf，将可变参数与传入数据拼接，生成最终的字符串数据；

系统调用触发：通过write函数，向内核发起 "写标准输出" 的请求，此时会触发int 0x80或syscall的陷阱指令，切换到内核态；

内核驱动处理：内核的字符显示驱动接收请求，将字符串对应的 ASCII 码转换为字模库中的点阵数据，写入显示缓存vram，存储每个像素的 RGB 颜色信息；

硬件显示输出：显示芯片按刷新频率逐行读取 vram 中的数据，通过信号线将 RGB 分量传输到显示器，最终呈现字符内容。

8.3.2 关键组件的作用

vsprintf：负责字符串的格式化拼接，是用户态的核心处理逻辑；

write系统调用：作为用户态与内核态的桥梁，实现数据从应用层到内核层的传递；

显示驱动：完成 "字符→点阵→像素" 的转换，是硬件无关性与硬件控制的中间层；

vram：作为显示数据的临时存储区，实现 "缓存数据→硬件读取" 的异步配合。

8.4 getchar的实现分析

8.4.1 核心执行流程

getchar的实现基于硬件中断→内核缓冲→系统调用→用户态读取的异步响应过程：

键盘中断触发：当用户按下按键时，键盘硬件会产生中断信号，内核的键盘中断处理子程序被唤醒；

扫描码转 ASCII：中断程序读取键盘发送的扫描码，将其转换为对应的 ASCII 码，并保存到内核维护的键盘缓冲区；

系统调用读取：getchar调用read系统函数，向内核请求读取标准输入（stdin）；内核从键盘缓冲区中取出 ASCII 码，通过系统调用返回给用户态；

阻塞等待机制：若键盘缓冲区为空，getchar会进入阻塞状态，直到有新的按键触发中断、填充缓冲区后，才会被唤醒并返回数据，直到读取到回车键时完成本次调用。

8.4.2 关键机制的意义

中断驱动：避免了用户态程序轮询键盘状态，提升了系统资源利用率；

内核缓冲区：实现了 "按键输入→程序读取" 的异步解耦，支持多字符的暂存；

阻塞调用：让用户态程序可以简洁地等待输入，无需处理复杂的异步逻辑。

8.5本章小结

本章围绕 Linux "一切皆文件" 的 I/O 设计思想，剖析 hello 进程的 I/O 交互机制。Linux 将键盘、显示器等 I/O 设备抽象为 /dev 目录下的设备文件，通过统一的 Unix I/O 接口屏蔽硬件差异，应用程序仅需通过文件描述符操作设备。printf 的实现流程为 "用户态格式化→ write系统调用 → 内核显示驱动 → vram → 显示器"，完成字符到像素的转换；getchar 则基于 "键盘中断→扫描码转 ASCII→内核缓冲区→read 系统调用" 的异步响应，阻塞等待机制避免用户态轮询，提升资源利用率。实验表明，无论是标准输出还是标准输入，其操作均通过文件接口与系统调用实现，体现了 I/O 管理 "分层抽象""软硬结合" 的特点。本章不仅解析了 printf/getchar 的底层逻辑，更验证了 Linux I/O 子系统如何通过设备驱动、缓冲区、中断机制，实现 "高效、统一、安全" 的设备访问，为理解应用程序与外部设备的交互提供了系统视角。

（第8章 1分）

结论

一、hello 程序生命周期的核心过程总结

程序构建阶段：从 hello.c 源码出发，预处理展开头文件与宏，生成 hello.i；编译将 C 语言转换为汇编指令，生成 hello.s；汇编将汇编转换为机器码，生成含符号表的 hello.o；链接整合库文件与重定位地址，生成可执行文件 hello，完成 "Program→可执行文件" 的转换。

进程运行阶段：Shell 通过 fork 创建子进程，execve 加载 hello 程序，OS 为其分配虚拟地址空间；存储管理模块通过四级页表、TLB、三级 Cache 实现虚拟地址到物理地址的高效转换；CPU 调度器分配时间片，使 hello 按 "取指 - 译码 - 执行" 流程运行，printf/getchar 通过 Unix I/O 接口与设备交互，完成打印与输入等待。

进程终止阶段：hello 执行完毕，返回 0 给父进程 Shell；Shell 调用 waitpid 回收资源，OS 释放 PCB、虚拟内存、文件描述符等，进程生命周期结束，实现 "From Zero-0 to Zero-0" 的闭环。

二、计算机系统设计与实现的感悟

分层抽象是核心思想：从高级语言→汇编→机器码，从虚拟地址→线性地址→物理地址，从设备→设备文件→文件接口，每一层均通过抽象屏蔽底层细节，既简化应用开发，又便于系统扩展。

资源复用提升效率：写时复制避免物理内存浪费，动态链接减少可执行文件体积，三级 Cache 复用热点数据，虚拟内存复用物理内存页，这些机制均体现 "以时间换空间" 或 "以空间换时间" 的权衡，是系统高效运行的关键。

软硬协同保障功能：硬件与软件紧密配合，如 TLB 加速地址转换、中断处理键盘输入，缺少任何一方均无法实现高效的资源管理与设备交互。

三、创新理念与改进建议

内存映射的可视化工具开发：现有 pmap/readelf 工具输出较零散，可开发轻量级可视化工具，将虚拟地址空间的段布局、页表映射、Cache 命中情况以图表形式展示，帮助开发者更直观理解存储管理机制。

信号处理的自定义扩展：hello 当前使用信号默认处理逻辑，可添加 signal/sigaction 函数，自定义 SIGINT 信号的处理，如收到 Ctrl+C 时，先打印 "程序即将退出" 再终止，增强程序的友好性，同时验证 "可捕获信号的自定义处理" 机制。

hello 程序虽简单，但其生命周期涵盖了编译原理、操作系统、计算机组成的核心知识点。通过本次大作业，不仅掌握了 gcc/gdb/readelf 等工具的实操技能，更深刻理解了计算机系统是 "硬件与软件协同工作的复杂整体"------ 任何一个环节的问题，都会导致程序无法正常运行。这一认知为后续深入学习奠定了坚实的实践基础。

（结论 0 分，缺失- 1 分）

附件

hello.c：存储 hello 程序的 C 语言源码，包含参数校验、循环打印、休眠与等待输入逻辑。

hello.i：预处理后的中间文件，展开 stdio.h/unistd.h/stdlib.h 头文件，删除注释与宏替换。

hello.s：汇编语言文件，将 C 语言逻辑转换为 x86-64 架构的汇编指令，包含代码段与数据段定义。

hello.o：可重定位目标文件，存储机器码、符号表与重定位条目，未解决外部依赖。

Hello：可执行文件，整合 hello.o 与系统库，分配虚拟地址，支持直接加载运行。

（附件0分，缺失 -1分）

参考文献

1\] Randal E. Bryant, David R. O'Hallaron. 深入理解计算机系统（原书第3版）\[M\]. 龚奕利，贺莲，译. 北京：机械工业出版社，2016：32-89，156-210，345-402. \[2\] 俞甲子，石凡，潘爱民. 程序员的自我修养------链接、装载与库\[M\]. 北京：电子工业出版社，2009：78-125，201-243. \[3\] 鸟哥. Linux私房菜------基础学习篇（第4版）\[M\]. 北京：人民邮电出版社，2018：456-512，623-678. \[4\] KANAMORI H. Shaking Without Quaking\[J\]. Science，1998，279(5359)：2063-2064. \[5\] 计算机系统原理课程组. HIT-CSAPP2025大作业参考资料\[EB/OL\]. (2025-09). https://ysyx.oscc.cc/slides/hello-x86.html. ****（参考文献0分，缺失 -1分）****