深入理解Linux内核-并发-系统调用

在应用程序和硬件间设置一个额外层优点：
(1). 使得编程更加容易，把用户从学习硬件设备的低级编程特性中解放出来．
(2). 极大提高了系统的安全性，内核在试图满足某个请求前在接口级就可检查这种请求的正确性．
(3). 接口使得程序更具有可移植性．

Unix系统通过向内核发出系统调用实现了用户态进程和硬件设备间的大部分接口．

POSIX API和系统调用

API：一个函数定义，说明了如何获得一个给定的服务．
系统调用：通过软中断向内核态发出一个明确的请求．

Unix系统给程序员提供了很多API的库函数。libc的标准C库所定义的一些API引用了封装例程。通常下，每个系统调用应对应一个封装例程，而封装例程定义了应用程序使用的API．

一个API没必要对应一个特定的系统调用。首先，API可能直接提供用户态的服务。其次，一个单独的API函数可能调几个系统调用。Posix标准针对API而不针对系统调用，判断一个系统是否与POSIX兼容要看它是否提供了一组合适的应用程序接口，而不管对应的函数是如何实现的。事实上，一些非Unix系统被认为是与POSIX兼容的。因为它们在用户态的库函数中提供了传统Unix能提供的所有服务．

从编程者观点看，API和系统调用间的差别没关系：唯一相关的事情就是函数名，参数类型，返回代码的含义。从内核设计者观点看，这种差别确实有关系，因为系统调用属于内核，用户态的库函数不属于内核．

大部分封装例程返回一个整数，其值的含义依赖于相应的系统调用。返回值-1通常表示内核不能满足进程的要求。在libc库中定义的errno变量包含特定的出错码。

系统调用处理程序及服务例程

当用户态的进程调一个系统调用时，CPU切换到内核态并开始执行一个内核函数。在80x86体系结构中，可用两种不同的方式调Linux的系统调用。两种方式的最终结果都是跳转到所谓系统调用处理程序的汇编语言函数．

因为内核实现了很多不同的系统调用，故进程必须传递一个名为系统调用号的参数来识别所需的系统调用，eax寄存器就用作此目的。当调用一个系统调用时通常还要传递另外的参数．

所有的系统调用都返回一个整数值，这些返回值与封装例程返回值的约定不同，在内核中，正数或0表示系统调用成功结束，负数表示一个出错条件。后一种情况下，这个值就是存放在errno中必须返回给应用的负出错码。内核没设置或使用errno变量，而封装例程从系统调用返回后设置这个变量。

系统调用处理程序与其他异常处理程序结构类似，执行：
(1). 在内核态保存大多数寄存器的内容．
(2). 调名为系统调用服务例程的相应C函数来处理系统调用．
(3). 退出系统调用处理程序：用保存在内核栈中的值加载寄存器，CPU从内核态切换回用户态．

为了把系统调用号与相应的服务例程关联起来，内核利用了一个系统调用分派表。这个表存放在sys_call_table数组，有NR_syscalls个表项，第n个表项包含系统调用号为n的服务例程的地址。

NR_syscalls只是对可实现的系统调用最大个数的静态限制，并不表示实际已实现的系统调用个数。实际上，分派表中的任意一个表项也可包含sys_ni_syscall函数的地址。这个函数是"未实现"系统调用的服务例程，它仅仅返回出错码-ENOSYS．

进入和退出系统调用

本地应用可通过两种不同方式调系统调用：
(1). 执行int $0x80，在Linux内核老版本，这是从用户态切换到内核态的唯一方式。
(2). 执行sysenter，在Intel Pentium 2中引入了这条指令，Linux 2,6内核支持此指令。
同样，内核可通过两种方式从系统调用退出，从而使CPU切换回用户态
(1). 执行iret;(2). 执行sysexit。

但支持进入内核的两种不同方式不像看起来那么简单：
(1). 内核必须既支持只使用int $0x80;也支持sysenter．
(2). 使用sysenter的标准库必须能处理仅支持int $0x80的旧内核．
(3). 内核和标准库必须既能运行在不包含sysenter指令的旧处理器上；也能运行在包含它的新处理器上．

通过int $0x80发出系统调用

向量128对应于内核入口点，在内核初始化期间调的函数trap_init用下面的方式建立对应于向量128的中断描述符表项：

set_system_gate(0x80, &system_call);

该调用把下列值存入这个门描述符的相应字段
(1). Segment Selector
内核代码段__KERNEL_CS的段选择符．
(2). Offset
指向system_call系统调用处理程序的指针．
(3). Type
15，表示这个异常是一个陷阱。相应的处理程序不禁止可屏蔽中断．
(4). DPL
3，允许用户态进程调这个异常处理程序．

当用户态进程发出int $0x80时，CPU切换到内核态并开始从地址system_call处开始执行指令．

system_call

首先把系统调用号和这个异常处理程序可用到的所有CPU寄存器保存到相应栈，不包含由控制单元已自动保存的eflags，cs，eip，ss和esp。在第4章已经讨论的SAVE_ALL，也在ds和es中装入内核数据段的段选择符．

system_call:
	pushl %eax
	SAVE_ALL
	movl $0xffffe000, %ebx
	andl %esp, %ebx

随后，这个函数在ebx中存放当前进程的thread_info的地址。这是通过获得内核栈指针的值并把它取整到4KB或8KB的倍数而完成的

接下来，system_call检查thread_info结构flag字段的TIF_SYSCALL_TRACE和TIF_SYSCALL_AUDIT之一是否被设置为1，即检查是否有某一调试程序正在跟踪执行程序对系统调用的调用。如是，则system_call两次调do_syscall_trace：一次正好在这个系统调用服务例程执行前，一次在其之后，这个函数停止current，并因此允许调试进程收集关于current的信息。然后， 对用户进程传递来的系统调用号进行有效性检查。如这个号大于或等于系统调用分派表中的表项数，系统调用处理程序就终止

	cmpl $NR_syscalls, %eax
	jb nobadsys
	movl $(-ENOSYS), 24(%esp)
	jmp resume_userspace
nobadsys:

如系统调用号无效，该函数就把-ENOSYS值存放在栈中曾保存eax寄存器的单元中（从当前栈顶开始偏移量为24的单元），然后跳到resume_userspace。这样，当进程恢复它在用户态的执行时，会在eax中发现一个负的返回码。最后，调与eax中所包含的系统调用号对应的特定服务例程．

call *sys_call_table(0, %eax, 4)

因为分派表中的每个表项占4个字节，故首先把系统调用号乘以4，再加上sys_call_table分派表的起始地址。然后从这个地址单元获取指向服务例程的指针，内核就找到了要调用的服务例程．

从系统调用退出

当系统调用服务例程结束时，system_call从eax获得它的返回值，把这个返回值存放在曾保存用户态eax寄存器值的那个栈单元的位置上．

movl %eax, 24(%esp)

故，用户态进程将在eax中找到系统调用的返回码。然后，system_call关闭本地中断并检查当前进程的thread_info结构中的标志．

cli
movl 8(%ebp), %ecx
testw $0xffff, %cx
je restore_all

flags字段在thread_info结构中的偏移量为8，所有标志都没设置，函数就跳到restore_all。restore_all恢复保存在内核栈中的寄存器的值，并执行iret以重新开始执行用户态进程．

只要任何一种标志被设置，则就要在返回用户态之前完成一些工作。如TIF_SYSCALL_TRACE被设置，system_call就第二次调do_syscall_trace，然后跳到resume_userspace；否则，如TIF_SYSCALL_TRACE没被设置，就跳到work_pending。在resume_userspace和work_pending处的代码检查重新调度请求，虚拟8086模式，挂起信号，单步执行，最终跳到restore_all处以恢复用户态进程的运行．

通过sysenter发出系统调用

int由于要执行几个一致性检查和安全性检查，故速度慢。在Intel文档中被称为"快速系统调用"的sysenter指令，提供了一种从用户态到内核态的快速切换方法．

sysenter

使用三种特殊的寄存器，它们需装入以下信息
(1). SYSENTER_CS_MSR
内核代码段的段选择符．
(2). SYSENTER_EIP_MSR
内核入口点的线性地址．
(3). SYSENTER_ESP_MSR
内核堆栈指针．

执行sysenter指令时，CPU控制单元：
(1). 把SYSENTER_CS_MSR内容拷贝到cs．
(2). 把SYSENTER_EIP_MSR内容拷贝到eip．
(3). 把SYSENTER_ESP_MSR内容拷贝到esp．
(4). 把SYSENTER_CS_MSR加8值装入ss．
故，CPU切换到内核态并开始执行内核入口点的第一条指令．

在内核初始化期间，一旦系统中的每个CPU执行enable_sep_cpu，三个特定于模型的寄存器就由该函数初始化。
enable_sep_cpu执行：
(1). 把内核代码__KERNEL_CS的段选择符写入SYSENTER_CS_MSR．
(2). 把下面要说明的函数sysenter_entry的线性地址写入SYSENTER_CS_EIP．
(3). 计算本地TSS末端的线性地址，把这个值写入SYSENTER_CS_ESP，对SYSENTER_CS_ESP的设置有必要进行一些说明。系统调用开始的时候，内核堆栈是空的。故，esp寄存器应指向4KB或8KB内存区域的末端。该内存区域包括内核堆栈和当前进程的描述符，因为用户态的封装例程不知这个内存区域的地址，所以它不能正确设置此寄存器。另一方面，必须在切换到内核态前设置该寄存器的值。故，内核初始化这个寄存器以便为本地CPU的任务状态段编址。

每次进程切换时，内核把当前进程的内核栈指针保存到本地TSS的esp0。这样，系统调用处理程序读esp，计算本地TSS的esp0，把正确的内核堆栈指针装入esp．

vsyscall页

只要CPU和Linux都支持sysenter，标准库libc中的封装函数就可使用。这个兼容性问题需要复杂的解决方案。本质上，初始化阶段sysenter_setup建立一个称为vsyscall页的页框。其中包括一个小的EFL共享对象（一个小的EFL动态链接库），当进程发出execve开始执行一个ELF程序时，vsyscall页中的代码会自动被链接到进程的地址空间，vsyscall页中的代码使用最有用的指令发出系统调用．

sysenter_setup为vsyscall页分配一个新页框，把它的物理地址与FIX_VSYSCALL固定映射的线性地址相关联。函数sysenter_setup把预先定义好的一个或两个EFL共享对象拷贝到该页．
(1). 如CPU不支持sysenter，sysenter_setup建立一个包含下列代码的vsyscall页

__kernel_vsyscall:
	int $0x80
	ret

(2). 否则，如CPU的确支持sysenter，sysenter_setup建立一个包括下列代码的vsyscall页

__kernel_vsyscall:
	pushl %ecx
	pushl %edx
	pushl %ebp
	movl %esp, %ebp
	sysenter

当标准库中的封装例程必须调系统调用时，调__kernel_vsyscall，不管它的实现代码是什么，最后一个兼容问题是由于老版本Linux内核不支持sysenter。此情况下，内核当然不建立vsyscall页，且函数__kernel_vsyscall不会被链接到用户态进程的地址空间，当新近的标准库识别这种状况后，简单执行int $0x80调系统调用

进入系统调用

当用sysenter发出系统调用时，依次执行下述：
(1). 标准库的封装例程把系统调用号装入eax寄存器调__kernel_vsyscall
(2). __kernel_vsyscall把ebp，edx，ecx的内容保存到用户态堆栈（系统调用处理程序将使用这些寄存器），把用户栈指针拷贝到ebp，执行sysenter
(3). CPU从用户态切换到内核态，内核开始执行sysenter_entry（由SYSENTER_EIP_MSR指向）
(4). sysenter_enter执行下述：
(4.1). 建立内核堆栈指针，movl -508(%esp), %esp，开始时，esp寄存器指向本地TSS的第一个位置，本地TSS的大小为512字节。故，sysenter把本地TSS中偏移量为4处的字段的内容（esp0）装入esp。esp0总是存放当前进程的内核堆栈指针
(4.2). 打开本地中断，sti。
(4.3). 把用户数据段的段选择符，当前用户栈指针，eflags，用户代码段的段选择符及从系统调用退出时要执行的指令的地址保存到内核堆栈

pushl $(__USER_DS)
pushl %ebp
pushfl
pushl $(__USER_CS)
pushl $SYSENTER_RETURN

这些指令仿效int所执行的一些操作
(4.4). 把原来由封装例程传递的寄存器的值恢复到ebp，movl (%ebp), %ebp，上面这指令完成恢复工作，因为__kernel_vsyscall把ebp原始值存入用户态堆栈，在随后把用户堆栈指针的当前值装入ebp
(4.5). 通过执行一系列指令调用系统调用处理程序，这些指令与前面通过int $0x80指令发出系统调用。一节描述的在system_call处开始的指令是一样的

退出系统调用

系统调用服务例程结束时，sysenter_entry本质上执行与system_call相同的操作
首先，它从eax获得系统调用服务例程的返回码，将返回码存入内核栈中保存用户态eax寄存器值的位置。然后，函数禁止本地中断，检查current的thread_info结构中的标志

如有任何标志被设置，则在返回到用户态前需完成一些工作，为避免代码复制，函数跳到resume_userspace或work_pending处。最后，汇编语言指令iret从内核堆栈中取五个参数，这样CPU切换到用户态并开始执行SYSENTER_RETURN标记处代码

如sysenter_entry确定标志被清0，它就快速返回到用户态

movl 40(%esp), %edx
movl 52(%esp), %ecx
xorl %ebp, %ebp
sti
sysexit

把在上一节由sysenter_entry函数在第4c步保存的一对堆栈值加载到edx和ecx，edx获得SYSENTER_RETURN标记处地址，而ecx获得当前用户数据栈的指针

sysexit

sysexit是与sysenter配对的指令，它允许从内核态快速切换到用户态，执行此指令时，CPU控制单元执行下述：
(1). 把SYSENTER_CS_MSR的值加16结果加载到cs
(2). 把edx寄存器的内容拷贝到eip
(3). 把SYSENTER_CS_MSR中的值加24得到的结果加载到ss
(4). 把ecx的内容拷贝到esp，因为SYSENTER_CS_MSR加载的是内核代码的选择符，cs加载的是用户代码的选择符，ss加载的用户数据段的选择符。结果，CPU从内核态切换到用户态，开始执行其地址存放在edx中的那条指令

SYSENTER_RETURN

存放在vsyscall页，当通过sysenter进入的系统调用被iret或sysexit终止时，该页框中的代码被执行。该代码恢复保存在用户态堆栈中的ebp,edx,ecx寄存器的原始内容，并把控制权返回给标准库中的封装例程

SYSENTER_RETURN:
	popl %ebp
	popl %edx
	popl %ecx
	ret

参数传递

系统调用通常也许输入/输出参数，这些参数可能是实际的值。也可能是用户态进程地址空间的变量，甚至是指向用户态函数的指针的数据结构地址，因为system_call和sysenter_entry是Linux中所有系统调用的公共入口点。故每个系统调用至少有一个参数，即通过eax寄存器传递来的系统调用号。如，如一个应用程序调fork，则在执行int $0x80或sysenter之前就把eax置为2。因为这个寄存器的值由libc中的封装例程进行，故程序员通常不关系系统调用号。fork系统调用并不需其他的参数。不过，很多系统调用确实需由应用程序明确传递另外的参数，如mmap可能需多达6个额外参数。

普通c函数参数传递通过把参数值写入活动的程序栈，系统调用是横跨用户和内核的特殊函数。故，既不能用用户态栈也不能用内核态栈。发出系统调用前，系统调用的参数被写入CPU寄存器。在调用系统调用服务例程前，内核再把存放在CPU中的参数拷贝到内核态堆栈。因为，系统调用服务例程是普通的c函数。

为何内核不直接把用户态的栈拷贝到内核态的栈？
(1). 同时操作两个栈比较复杂
(2). 寄存器的使用使系统调用处理程序的结构与其他异常处理程序的结构类似
然而，为了用寄存器传递参数，需满足：
(1). 每个参数的长度不能超过寄存器的长度， 即32位
(2). 参数的个数不能超过6个（除eax中传递的系统调用号），因为80x86处理器的寄存器数量有限

确实存在多于6个参数的系统调用，在此情况下，用一个单独的寄存器指向进程地址空间中这些参数值所在的一个内存区，编程者不用关心此工作区。调封装例程时，参数被自动保存在栈。封装例程将找到合适的方式把参数传递给内核，用于存放系统调用号和系统调用参数的寄存器是：
eax：系统调用号，ebx，ecx，edx，esi，edi，ebp
system_call和sysenter_entry使用SAVE_ALL把这些寄存器保存在内核态堆栈。故，系统调用服务例程转到内核堆栈时，会找到system_call或sysenter_entry的返回地址，接着是存放在ebx中的参数，存放在ecx中的参数等。系统调用服务例程容易通过用c语言结构来引用它的参数，例

int sys_write(unsigned int fd, const char * buf, unsigned int count)
int sys_fork(struct pt_regs regs)

服务例程的返回值必须写入eax寄存器中。这是在执行“return n;”指令时由C编译程序自动完成的。

验证参数

访问进程地址空间

系统调用服务例程需要非常频繁地读写进程地址空间的数据。Linux包含的一组宏使这种访问更加容易。我们将描述其中的两个名为get_user()和put_user()的宏。
第一个宏用来从一个地址读取1、2或4个连续字节，而第二个宏用来把这几种大小的内容写入一个地址中。这两个函数都接收两个参数，一个要传送的值x和一个变量ptr。第二变量还决定有多少个字节要传送。因此，在get_user(x, ptr)中，由ptr指向的变量大小使该函数展开为__get_user_1()、__get_user_2()或__get_user_4()汇编语言函数。让我们看一下其中一个，比如，__get_user_2():

__get_user_2:
	addl $1,%eax
	jc bad_get_user
	movl $0xffffe000, %edx /*or xxfffff000 for 4-kb stacks */
	andl %esp,%edx
    cmpl 24(%edx), %eax
    jae bad_get_user
2: movzwl -1(%eax), %edx 
   	xorl %eax, %eax
	ret
bad_get_user:
	xorl %edx, %edx
	movl $-EFAULT, %eax
	ret

eax寄存器包含要读取的第一个字节的地址ptr。前6个指令所执行的检查事实上与access_ok()宏相同，即确保要读取的两个字节的地址小于4GB并小于current进程的addr_limit.seg字段(这个字段位于current的thread_info结构中偏移量为24处，出现在cmpl指令的第一个操作数中)。如果这个地址有效，函数就执行movzwl指令，把要读的数据存到edx寄存器的两个低字节，而把两个高字节置为0，然后在eax中设置返回码0并终止。如果这个地址无效，函数清edx，将eax置为-EFAULT并终止。put_user(x,ptr)宏类似于前边讨论的get_user，但它把值x写入以地址ptr为起始地址的进程地址空间。

根据x的大小，它使用__put_user_asm()宏(大小为1、2或4字节)，或__put_user_u64()宏(大小为8字节)。这两个宏如果成功地写入了值那它们在eax寄存器中返回0，否则返回-EFAULT。在表10-1中列出了内核态下用来访问进程地址空间的另外几个函数或宏。注意，许多函数或宏的名字前缀有两个下划线(__)。首部没有下划线的函数或宏要用额外的时间对所请求的线性地址区间进行有效性检查，而有下划线的则会跳过检查。当内核必须重复访问进程地址空间的同一块线性区时，比较高效的办法是开始时只对该地址检查一次，以后就不用再对该进程区进行检查了。

动态地址检查：修正代码

我们先说明一下在内核态引起缺页异常的四种情况。这些情况必须由缺页异常处理程序来区分，因为不同情况采取的操作很不相同：
(1). 内核试图访问属于进程地址空间的页，但是，或者是相应的页框不存在，或者是内核试图去写一个只读页（写时复制）。在这些情况下，处理程序必须分配和初始化一个新的页框
(2). 内核寻址到属于其地址空间的页，但是相应的页表项还没有被初始化(参见第九章“处理非连续内存区访问”一节)。在这种情况下，内核必须在当前进程页表中适当地建立一些表项。也会分配页框。
(3). 某一内核函数包含编程错误，当这个函数运行时就引起异常；或者，可能由于瞬时的硬件错误引起异常。当这种情况发生时，处理程序必须执行一个内核漏洞(参见第九章的“处理地址空间以外的错误地址”一节)。
(4). 本章所讨论的一种情况：系统调用服务例程试图读写一个内存区，而该内存区的地址是通过系统调用参数传递来的，但却不属于进程的地址空间。

异常表

把访问进程地址空间的每条内核指令的地址放到一个叫异常表(exception table)的结构中并不用费太多功夫。当在内核态发生缺页异常时，do_page_fault()处理程序检查异常表：如果表中包含产生异常的指令地址，那么这个错误就是由非法的系统调用参数引起的，否则，就是由某一更严重的bug引起的。

Linux定义了几个异常表。主要的异常表在建立内核程序映像时由C编译器自动生成。它存放在内核代码段的__ex_table节，其起始与终止地址由C编译器产生的两个符号__start__ex_table和__stop__ex_table来标识。每个动态装载的内核模块(参看附录二)都包含有自己的局部异常表。这个表是在建立模块映像时由C编译器自动产生的，当把模块插入到运行中的内核时把这个表装入内存。每一个异常表的表项是一个exception_table_entry结构，它有两个字段：
(1). insn
访问进程地址空间的指令的线性地址。
(2). fixup
当存放在insn单元中的指令所触发的缺页异常发生时，fixup就是要调用的汇编语言代码的地址。

修正代码由几条汇编指令组成，用以解决由缺页异常所引起的问题。在后面我们将会看到，修正通常由插入的一个指令序列组成，这个指令序列强制服务例程返回一个出错码给用户态进程。这些指令通常在访问进程地址空间的同一函数或宏中定义；由C编译器把它们放置在内核代码段的一个叫作.fixup的独立部分。search_exception_tables()函数用来在所有异常表中查找一个指定地址：若这个地址在某一个表中，则返回指向相应exception_table_entry结构的指针；否则，返回NULL。因此，缺页处理程序do_page_fault()执行下列语句：

if((fixup = search_exception_tables(regs->eip))){
	regs->eip = fixup->fixup;
	return 1;
}

regs->eip字段包含异常发生时保存到内核态栈eip寄存器中的值。如果eip寄存器(指令指针)中的这个值在某个异常表中，do_page_fault()就把所保存的值替换为search_exception_tables()的返回地址。然后缺页处理程序终止，被中断的程序以修正代码的执行而恢复运行。

生成异常表和修正代码

GNU汇编程序(Assembler)伪指令.section允许程序员指定可执行文件的哪部分包含紧接着要执行的代码。可执行文件包括一个代码段，这个代码段可能又依次被划分为节。因此，下面的汇编指令在异常表中加入一个表项；“a”属性指定必须把这一节与内核映像的剩余部分一块加载到内存中。

.previous伪指令强制汇编程序把紧接着的代码插入到遇到上一个.section伪指令时激活的节。让我们再看一下前面论及过的__get_user_1()、__get_user_2()和__get_user_4()函数。访问进程地址空间的指令用1、2和3标记。


每个异常表项由两个标号组成。第一个是一个数字标号，其前缀b表示标号是“向后的”；换句话说，标号出现在程序的前一行。修正代码对这三个函数是公用的，且被标记为bad_get_user。如果缺页异常是由标号1、2或3处的指令产生的，那么修正代码就执行。在bad_get_user处的修正代码给发出系统调用的进程只简单地返回一个出错码-EFAULT。

内核封装例程

尽管系统调用主要由用户态进程使用，但也可以被内核线程调用，内核线程不能使用库函数。为了简化相应封装例程的声明，Linux定义了7个从_syscal10到_syscall6的一组宏。

每个宏名字中的数字0~6对应着系统调用所用的参数个数(系统调用号除外)。也可以用这些宏来声明没有包含在libc标准库中的封装例程(例如，因为Linux系统调用还未受到库的支持)。然而，不能用这些宏来为超过6个参数(系统调用号除外)的系统调用或产生非标准返回值的系统调用定义封装例程。每个宏严格地需要2+2×n个参数，n是系统调用的参数个数。前两个参数指明系统调用的返回值类型和名字；每一对附加参数指明相应的系统调用参数的类型和名字。因此，以fork()系统调用为例，其封装例程可以通过如下语句产生：_syscall0(int, fork)。而write()系统调用的封装例程可以通过如下语句产生：_syscall3(int, write, int, fd, const char *, buf, unsigned int, count)．

#define _syscall3(type,name,type1,arg1,type2,arg2,type3,arg3) \
type name(type1 arg1,type2 arg2,type3 arg3) \
{ \
long __res; \
__asm__ volatile ("int $0x80" \
	: "=a" (__res) \
	: "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2)), \
		  "d" ((long)(arg3))); \
__syscall_return(type,__res); \
}

#define __syscall_return(type, res) \
do { \
	if ((unsigned long)(res) >= (unsigned long)(-(128 + 1))) { \
		errno = -(res); \
		res = -1; \
	} \
	return (type) (res); \
} while (0)

在后一种情况下，可以把这个宏展开成如下的代码：


__NR_write宏来自_syscal13的第二个参数；它可以展开成write()的系统调用号。当编译前面的函数时，生成下面的汇编代码：

额外说明

代码段中插入了.section xxx这样的段定义，代码段顺序执行时，是否会接着执行.section xxx中的指令？不会。可以理解为.section xxx这样的定义会使得编译器编译可执行文件时，将.section xxx中的内容放在额外的节中。这样，实际的可执行文件中，.section xxx前面的可执行指令，和.section xxx中的可执行指令并不是相邻的。

xxx1
.section yyy1
...
.previous
.section yyy2
...
.previous
xxx2

上述指令序列，编译出的可执行文件中

section yy1
	...
	xxx1
	xxx2
	...
section yyy1
	...
section yyy2
	...

所以，xxx1指令执行后，接着执行的是xxx2代表的指令

#define __put_user_asm(x, addr, err, itype, rtype, ltype, errret)	\
	__asm__ __volatile__(						\
		"1:	mov"itype" %"rtype"1,%2\n"			\
		"2:\n"							\
		".section .fixup,\"ax\"\n"				\
		"3:	movl %3,%0\n"					\
		"	jmp 2b\n"					\
		".previous\n"						\
		".section __ex_table,\"a\"\n"				\
		"	.align 4\n"					\
		"	.long 1b,3b\n"					\
		".previous"						\
		: "=r"(err)						\
		: ltype (x), "m"(__m(addr)), "i"(errret), "0"(err))