程序员如何定义自己的程序段

女神18号

节目为什么要分成几个段落？

第一，运行程序不一定要分段，分段是为了使程序更加漂亮。

就像用饭盒装饭菜一样，完全可以将很多菜和米饭混合在一起，或者搅拌成一体，哈哈，但这样可能就没什么胃口啦^_^。如果饭盒中有好多小格子，方便将不同的菜和饭区分存放，这样会让我们胃口大开增加食欲。

x86平台的处理器是必须要用分段机制访问内存的，正因为如此处理器才提供了段寄存器，用来指定待访问的内存段起始地址。我们这里讨论的程序代码中的段（用section或segment来定义的段，不同汇编编译器提供的关键字有所区别，功能是一样的）和内存访问机制中的段本质上是一回事。在硬件的内存访问机制中，处理器要用硬件——段寄存器，指向软件——程序代码中用section或segment以软件形式所定义的内存段。

分段是必然的，只是在平坦模型下，硬件段寄存器中指向的内存段为最大的4GB，而在多段模式下编程，硬件段寄存器中指向的内存段大小不一。

对于在代码中的分段，有的是操作系统做的，有的是程序员自己划分的。如果是在多段模型下编程，我们必然会在源码中定义多个段，然后需要不断地切换段寄存器所指向的段，这样才能访问到不同段中的数据，所以说，在多段模型下的程序分段是程序员人为划分的。如果是在平坦模型下编程，操作系统将整个4GB内存都放在同一个段中，我们就不需要来回切换段寄存器所指向的段。对于代码中是否要分段，这取决于操作系统是否在平坦模型下。

一般的高级语言不允许程序员自己将代码分成各种各样的段，这是因为该编译器是为针对某个操作系统编写的，该操作系统采用的是平坦模型，所以该编译器要编译出适合此操作系统加载运行的程序。由于处理器支持了分页机制的虚拟内存，操作系统也采用了分页模型，编译器则会将程序按内容划分成代码段和数据段，如编译器gcc会把c语言写出的程序划分成代码段、数据段、栈段、.bss段、堆等部分。这会由操作系统将编译器编译出来的用户程序中的各个段分配到不同的物理内存上。对于目前咱们用高级语言编码来说，我们之所以不用关心如何将程序分段，正是由于编译器按平坦模型编译，而程序所依赖的操作系统又采用了虚拟内存管理，即处理器的分页机制。像汇编这种低级语言允许程序员为自己的程序分段，能够灵活地编排布局，这就属于人为将程序分成段了，也就是采用多段模型编程。

这么说似乎不是很清楚，一会再用例子和大伙儿解释就明白了。在这之前，先和大家明确一件事。

cpu是个自动化极强的芯片，就像心脏一样，给它一个初始的收缩，它将永远地跳下去。

突然想到intel的广告词：给你一颗奔腾的心。

只要给出cpu第一个指令的起始地址，cpu在它执行本指令的同时，它会自动获取下一条的地址，然后重复上述过程，继续执行，继续取址。假如执行的每条指令都正确，没有异常发生的话，我想它可以运行到世界的尽头，能让它停下来的唯一条件就是断电。

它为什么能够取得下一条指令地址？也就是说为什么知道下一条指令在哪里。这是因为程序中的指令都是挨着的，彼此之间无空隙。有同学可能会问，程序中不是有对齐这回事吗？为了对齐，编译器在程序中塞了好多0。是的，对齐确实是让程序中出现了好多空隙，但这些空隙是数据间的空隙，指令间不存在空隙，下一条指令的地址是按照前面指令的尺寸大小排下来的，这就是intel处理器的程序计数器CS:eip 能够自动获得下一条指令的原理：将当前eip中的地址加上当前指令机器码的大小便是内存中下一条指令的起始地址。即使指令间有空隙或其它非指令的数据，这也仅仅是在物理上将其断开了，依然可以用jmp指令将非指令部分跳过以保持指令在逻辑上连续，我们在后面会通过实例验证这一原理。

为了让程序内指令接连不断地执行，要把指令全部排在一起，形成一片连续的指令区域，这就是代码段。这样cpu肯定能接连不断地执行下去。指令是由操作码和操作数组成的，这对于数据也一样，程序运行不仅要有操作码，也得有操作数，操作数就是指程序中的数据。把数据连续的并排在一起存储，形成的段落，就称为数据段。

指令大小是由实际指令的操作码决定的，也就是说cpu在译码阶段拿到了操作码后，就知道实际指令所占的大小。其实说来说去，本质上就是在解释地址是怎么来的。这部分在第三章中的小节“什么是地址”中有详解。

给大家演示个小例子，代码没有实际意义，是我随便写的，只是为方便大家理解指令的地址，如下面代码。

code_

本示例一共就5行，简单纯粹为演示。将其编译为二进制文件，程序内容是：

8E D8 A1 07 00 EB FE 99 00

就这9个字节的内容，有没有觉得一阵晕炫。如果没有，目测兄弟技术水平远在我之上，请略过^_^。

其实这9个字节的内容就是机器码。为了让大家理解的更清晰，给大家列个机器码和源代码对照表。

现在大伙儿明白为什么cpu能源源不断获取到指令了吧，如前所述，原因首先是指令是连续紧凑的，其次是通过指令机器码能够判断当前指令长度，当前指令地址+当前指令长度=下一条指令地址。表0-1第1行，地址0处的指令是“mov ds,ax”，其机器码是8ED8，这是16进制表示，可见其大小是2字节。前面说过啦，下一条指令的地址是按照前面指令的尺寸排下来的，那第2行指令是起始地址是0+2=2。在第2行的地址列中，地址确实是2。这不是我故意写上去的，编译器真的就是这样编排的。第2列的指令是“mov ax, [0x7]”（0x7是变量var经过编译后的地址），其机器码是A10700，这是3字节大小。所以第3条指令的地址是2+3=5。后面的指令地址也是这样推算的。程序虽然很短，但麻雀虽小，五脏俱全，完美展示了程序中代码紧凑无隙的布局。

上面给出的例子，其指令在物理上是连续的，其实在cpu眼里，只要指令逻辑上是连续的就可以，没必要一定得是物理上连续。所以，明确一点，即使数据和代码在物理上混在一起，程序也是可以运行的，这并不意味着指令被数据“断开”了。只要程序中有指令能够跨过这些数据就行啦，最典型的就是用jmp跳过数据区。

这几行代码没有实际意义，只是为了解释清楚问题，咱们只要关注在第2行的定义变量var之前为什么要jmp start。如果将上面的汇编代码按纯二进制编译，如果不加第1行的jmp，cpu也许会发出异常，显示无效指令，也许不知道执行到哪里去了。因为 cpu只会执行cs：ip中的指令，这两个寄存器记录的是下一条待执行指令的地址，下一个地址var处的值为1,显然我们从定义中看出这只是数据，但指令和数据都是二进制数字，cpu可分不出这是指令还是数据。保不准某些“数据”误打误撞恰恰是某种指令也说不定。既然var是我们定义的数据，所以必须加上jmp start跳过这个var所占的空间才可以。

加个jmp指令，这样做一点都不影响运行，只不过这写出来的程序，其中引用的地址大部分是不连续的，也就是程序在取地址时会显得跳来跳去的。就美观层面上看，这样的结构上显得很凌乱，不利于程序员阅读与维护。如果把第2行的var换到第1行，数据和代码就分开了，没有混在一起，标号都不用了，代码简洁多了，如下。

做过开发的同学都清楚，尽量把同一属性的数据放在一起，这样易于维护。这一点类似于MVC，在程序逻辑中把模型，视图，控制这三部分分开，这样更新各部分时，不会影响到其它模块。

将数据和代码分开的好处有三点:

第一，可以为他们赋予不同的属性。

比如数据本身是需要修改的，所以数据就需要有可写的属性，不让数据段可写，那程序根本就无法执行啦。程序中的代码是不能被更改的，这样就要求代码段具备只读的属性。真要是在运行过程中程序的下一条指令被修改了，谁知道会会产生什么样的灾难。

第二，为了提高CPU内部缓存的命中率。

大伙儿知道，缓存起作用的原因是程序的局部性原理。在CPU内部也有缓存机制，将程序中的指令和数据分离，这有利于增强程序的局部性。因此CPU内部有针对数据和针对指令的两种缓存机制，因此，将数据和代码分开存储将使程序运行更快。

第三，节省内存。

程序中存在一些只读的部分，比如代码，当一个程序的多个副本同时运行时（比如同时执行多个ls命令时），没必要在内存中同时存在多个相同的代码段，这将浪费有限的物理内存资源，只要把这一个代码段共享就可以了。

后两点较容易理解，咱们深入讨论下第一点，不知您有没有想过，数据段或代码段的属性是谁给添加上的呢，是谁又去根据属性保护程序的呢，是程序员吗？是编译器吗？是操作系统吗？还是cpu一级的硬件支持？

首先肯定不是程序员，人家操作系统设计人员为了让程序员编写程序更加容易，肯定不会让他们分心去处理这些与业务逻辑无关的事。看看编译器为我们做了什么，它将程序中那些只读的代码编译出来后，放在一片连续的区域，这个区域叫代码段。将那些已经初始化的数据也是放在一片连续的区域，这个区域叫数据段，那些具有全局属性的但又未初始化的数据放在bss段。总之，程序中段的类型可多了，用readelf –e elf可执行文件便可以看到很多段的类型，感兴趣的同学请自行查阅。好了，编译器的工作到此就完事了，显然，数据段和代码段的属性到现在还没有体现出来。

先看cpu为我们提供了哪些原生的支持。在保护模式下，有这样一个数据结构，它叫GDT(Global Descriptor Table)全局描述符表，这个表中的每一项称为段描述符。先递归学习一下，什么是描述符？描述符就是描述某种数据的数据结构，是元信息，属于数据的数据。就像人们的身份证，上面有写性别，出生日期，地址等描述个人情况的信息。在段描述符中有段的属性位，在以后的章节中可以看到，其实是有2个，一个是S字段，占1bit大小，另外一个是占4bit大小的TYPE字段，这两个字段配合在一起使用就能组合出各种属性，如：只读，向下扩展，只执行等等。提供归提供，可得有人去填写这张表啊，谁来做这事呢，有请操作系统登场。

接着看操作系统为我们做了什么。

操作系统在让cpu进入保护模式之前，首先要准备好GDT，也就是要设置好GDT的相关项,填写好段描述符。段描述符填写成什么样，段具备什么样的属性，这完全取决于操作系统了，在这里大家只要知道，段描述符中的S字段和TYPE字段负责该段的属性，也就是该属性与安全相关。

说到这里，答案似乎浮出水面了：

1. 编译器负责挑选出哪些数据具备怎样的属性，从而根据属性将程序片段分类，比如，划分出了只读属性的代码段和可写属性的数据段。再补充一下，编译器并没有让段具备某种属性，对于代码段，编译器所做的只是将代码归类到一起而已，也就是将程序中的有关代码的多个section合并成一个大的segment（这就是我们所说的代码段），它并没有为代码段添加额外的信息。

2. 操作系统通过设置GDT全局描述符表来构建段描述符，在段描述符中指定段的位置、大小及属性（包括S字段和TYPE字段）。也就是说，操作系统认为代码应该是只读的，所以给用来指向代码段的那个段描述符设置了只读的属性，这才是真正给段添加属性的地方。

3. cpu中的段寄存器提前被操作系统赋予相应的选择子（后面章节会讲什么是选择子，暂时将其理解为相当于段基址），从而确定了指向的段。在执行指令时，会根据该段的属性来判断指令的行为，若有返回则发出异常。

总之，编译器，操作系统，cpu三个配合在一起才能对程序保护，检测出指令中的违规行为。如果GDT中的代码段描述符具备可写的属性，那编译器再怎么划分代码段都没有用，有判断权利的只有cpu。

好，现在大家先有个感性认识，随着以后章节中讲GDT的时候，大家就会有深刻的理解了。

以上说明了程序按内容分段的原因，那编译器编译出来的段和内存访问中的段是一回事吗？

其实算一回事，也不算一回事。怎么说呢，我觉得当初intel在设计cpu时，其采用分段机制访问内存的原因，肯定不是为了上层软件的优美，毕竟那只是逻辑上的东西。那为什么也算一回事呢？

分析一下，编译出来的代码段是指一片连续的内存区域。这个段有自己的起始地址，有自己的大小。用户进程中的段只是为了便于管理，编译器或程序员在美学方面做出的规划。本质上并不是cpu用于内存访问的段，但他们都是描述了一段内存，而且程序中的段，其起始地址和大小可以理解为cpu访问内存分段策略中的“段基址:段内偏移地址”，这么说来，至少他们很接近了，让我们更近一步：程序是可以被人为划分成段的，并且可以将划分出来的段地址加载到段寄存器中。见下面代码0-1。

代码0-1 程序分段

在此提醒一下，各section中的定义都有align=16和vstart=0，这是用来指定各section按16位对齐，各section的起始地址是16的整数倍，即用16进制表示的话，最后一位是0。所以右移操作如第9行的shr ax,4，结果才是正确的，只是把0移出去了。否则不加align=16的话，section的地址不能保证是16的整数倍，右移4位可能会丢数据。vstart=0是指定各section内数据或指令的地址以0为起始编号，这样做为段内偏移地址时更方便。具体vstart内容请参阅本书相应章节。代码0-1是实模式下运行的程序，其中自定义了三个段，为了和标准的段名(.code、.data等)有所区别，这里代码段取名为my_code，数据段取名为my_data、栈段取名为my_stack。这段代码是由mbr加载到物理内存地址0x900后，mbr通过“jmp 0x900”跳过来的，我们的想法是让各段寄存器左移4位后的段基址与程序中各分段实际内存位置相同，所以对于代码段，希望其基址是0x900，故代码段CS的值为0x90（在实模式下，由cpu的段部件将其左移4位后变成0x900，所以要初始化成左移4位前的值）。但没有办法直接为CS寄存器赋值，所以在代码0-1开头，用“jmp 0x90:0”，初始化了程序计数器CS和IP。这样段寄存器CS就是程序中咱们自己划分的代码段了。

第6~10行是初始化数据段寄存器DS，是用程序中自已划分的段my_data的地址来初始化。由于代码0-1本身是脱离操作系统的程序，是MBR将其加载到0x900后通过跳转指令“jmp 0x900”跳入执行的，所以要将my_data在文件内的地址加上0x900才是最终在内存中的真实地址。右移4位的原因同代码段相同，都是cpu的段部件会自动将段基址左移4位，故提前右移4位。此地址做为段基址赋值给DS，这样段寄存器DS中的值是程序中咱们自己划分的数据段了。

第12~17行是初始化栈段寄存器，原理和数据段差不多，唯一区别是栈段初始化多了个针指针SP，为它初始化的值stack_top是最后一行，因为栈指针在使用过程中是越来越低，所以初始化时一定得是栈段的最高地址。

经过代码段、数据段、栈段的初始化，cpu中的段寄存器CS、DS、SS都是指向程序中咱们自己划分的段地址，之后cpu的内存分段机制“段基址：段内偏移地址”，段基址就是程序中咱们自己划分的段，段内偏移地址都是各自定义段内的指令和数据地址，由于自section中有vstart=0限制，所以地址都是从0编号。所以，程序中的分段和cpu内存访问的分段又是一回事。

让我们对此感到疑惑的原因，可能是我们一般都是用高级语言开发程序，在高级语言中，程序分段这种工作不由我们控制，是由编译器在编译阶段完成的。而且现代操作系统都是在平坦模型（整个4GB空间为1个段）下工作，编译器也是按照平坦模型为程序布局，程序中的代码和数据都在同一个段中整齐排列。大家可以用readelf –e /bin/ls查看一下ls命令，结果太长，就不截图啦。咱们主要关注三段内容：

• λSection Headers:中列出了程序中所有的section，这些section是gcc编译器帮忙划分的。

• λProgram Headers:中列出了程序中的段，即segment，这是程序中section合并后的结果。

• λSection to Segment mapping:列出了一个segment中包含了哪些section。

有关section和segment的内容请参见本书相关章节。

在Section Headers和Program Headers中您会发现，这些分段都是按照地址由低到高在4GB空间中连续整洁地分布，在平坦模型下和谐融洽。

显然，不用程序员手工分段，并且采用平坦模型，这种操作上的“隔离”故然让我们更加方便，但也让我们更加感到进程空间布局的神秘。如果程序分段像代码0-1那样地如此直白、亲民，大家肯定不会感到迷惑了。其实我想说的是，无论是否为平坦模型，程序中的分段和cpu中的内存分段机制，它们属于物品与容器的关系。

举个例子，程序中划分的段相当于各种水果，比如代码段相当于香蕉，数据段相当于葡萄，栈段相当于西瓜。cpu内存分段策略中的段寄存器相当于盛水果的盘子。可以用一个大盘子将各种水果都放进来，但依然是分门别类的摆放，不能失去美感混成一锅粥，这就是段大小为4GB平坦模型。也可以把每种水果分别放在一个小盘子里一块端上来，这就是普通的分段模型。如图0-4：

图0-4 程序中分段在平坦模型和分段模型中的区别

总结一下，程序中的段只是逻辑上的划分，用于不同数据的归类，但是可以用cpu中的段寄存器直接指向它们，然后用内存分段机制去访问程序中的段，在这一点上看，它们很像相片和相框的关系：程序中的段是内存中的内容，相当于相片，属于被展示的内容。而内存分段机制则是访问内存的手段，相当于相框，有了相框，照片才能有地摆放。

我想大家应该已经搞清楚了内存分段和程序分段的关系，其实就是一回事，内存分段指的是处理器为访问内存而采用的机制，称之为内存分段机制，程序分段是软件中人为逻辑划分的内存区域，它本身也是内存，所以处理器在访问该区域时，也会采用内存分段机制，用段寄存器指向该区域的起始地址。

就到这，人家好累。