在关于重定位机制的讨论中，我最初的想法就是在重定位表中保存符号名的字符串。被高级语言惯坏了的我们可以将字符串作为基本数据类型，但在C语言的结构体中变长字符串需要用指针指向一段结构体以外的空间来存储。那么字符串放在每段的最后，还是集中放在整个目标文件的最后，还是散落在任意的位置？不论怎样，乱堆乱放的字符串都对文件格式的统一性造成了破坏。程序中还要在内存中的字符串指针、文件中字符串的偏移量之间来回转换，没有统一的机制简直是一场噩梦。

ELF 文件格式中，存在两个专门的字符串表（section）：.strtab 用于普通字符串，如符号名；.shstrtab 用于段表中用到的字符串，如段名。（我不明白段表为什么得到了特殊待遇）字符串的存储方式很简单，每个字符串末尾用“\0”作为分界。注意到段名本身也是存储在字符串表中的，那么找到字符串表所在段就成了一个“鸡生蛋，蛋生鸡”的问题。事实上，ELF文件头中的 e_shstrndx 就是 .shstrtab 段在段表中的下标，而段表在文件中的偏移是 ELF 文件头中 e_shoff 指定的。ELF文件格式中这种一环扣一环的事情还真不少。

有了保存字符串的机制，存储各种符号就只需要指定其在字符串表中的下标（即第几个字符串）了。这样机器码中“放不下”的函数名、变量名就可以放到字符串表中，这需要做一个从符号在机器码中的位置到字符串表中符号名的映射。这个映射就是“符号表”（.symtab section）。事实上，符号表中的每一个结构体不仅描述了符号所在段、符号在段内的偏移、符号名在字符串表中的下标，还描述了符号类型（数据对象、函数、段、文件名等）、符号所对应数据类型的大小等。

符号表在动态语言的解释过程中是起到关键作用的。以 PHP 为例，“变量的变量”（即 $a=“varname”; $varname=100; $$a 的值为100）“执行动态生成代码”等“可怕”的功能，在 PHP 解释器中是用一个从变量名到内存中存储地址的映射实现的。

事实上，PHP的Zend引擎内部使用结构体zval来表示变量。用强类型实现弱类型并不复杂：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

typedef struct _zval_struct {
    zvalue_value value; // 变量的值
    zend_uint refcount; // 引用计数，用于写时复制
    zend_uchar type; // 变量类型
    zend_uchar is_ref; // 是否是引用（如果是引用，则写时不复制）
} zval;

typedef union _zvalue_value {
    long lval; // 整数类型（包括bool）、资源类型（用整数表示资源序号，类似C中的文件描述符）
    double dval; // 浮点类型
    struct {
        char *val;
        int len;
    } str; // 字符串类型
    HashTable * ht; // 关联数组类型（关联数组类似Python中的字典）（用hash表存储）
    zend_object_value obj; // 对象类型
} zvalue_value;

这不是一个很难想到的解决方案，当时设想做C语言在线解释器时就提出了类似的方案，以在弱类型的 javascript 中表示强类型的C变量。

在 PHP 的执行引擎 Zend 中，变量（zval）存储在 hash 表形式的符号表中，其 key 为变量名，value 为 zval。全局符号表保存了顶层作用域（即不在任何类、函数内）的变量，每个函数和类的方法在执行期间还有自己的一个符号表。调用一个函数或类的方法时，会为它创建一个符号表并设为活动（active）符号表，所有函数内定义的变量都保存在这个符号表中，从函数返回时销毁这个符号表。在函数或方法之外时，才会使用全局符号表。PHP 有个很奇怪的规定，在函数内使用全局变量需要用 global 声明，恐怕是与符号表有关吧。

PHP的函数是全局的，因此并不存储在符号表里。函数分为内部函数（internal function）和用户函数（user function），内部函数（用C写成的 PHP 核心及扩展中的函数）存储在函数表里，用户函数（用 PHP 写的函数）指向它的 Opcode（中间码）序列。由于本文重点不是 PHP，有兴趣的读者请自行参阅 zend_internal_function、zend_op_array、zend_function 三个结构体。类中的方法是有作用域（仅对类的实例有效）的，因而上述三个结构体中都有一个指向 “类”（zend_class_entry）的指针。执行一个函数时，如果在内部函数表中找到了作用域内的函数，则直接调用之；不然，在用户函数中寻找作用域内的函数，并调用 zend_execute 执行其 opcode。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

struct _zend_op {
    opcode_handler_t handler; // 处理函数，与opcode对应
    znode result; // 操作结果
    znode op1; // 操作数1
    znode op2; // 操作数2，不是每个操作都会同时使用result、op1、op2
    ulong extended_value; // 执行过程中需要的其他信息，是一组flags
    uint lineno; // 源码中的行号（调试和错误处理时用）
    zend_uchar opcode; // 操作类型，可以认为是指令（例如FETCH_W是以写的方式获取变量到“寄存器”，ASSIGN是赋值，ECHO是显示）
}

typedef struct _znode {
    // 操作数类型：常量、变量（用户可见的）、临时变量（引擎内部的）、编译后的变量（有点像寄存器，为了避免每次使用变量都去hash表里查询，效率太低）
    int op_type;
    union {
        zval constant; // 常量
        zend_uint var; // 变量（可见、临时）
        zend_uint opline_num; /* Needs to be signed */
        zend_op_array *op_array;
        zend_op *jmp_addr;
        struct {
            zend_uint var; /* dummy */
            zend_uint type;
        } EA; // 编译后的变量
    } u;
} znode;

回到C语言目标文件中的符号表，有个目前看来并不严重的问题：同名 extern 符号在不同文件中代表同一个符号，重复定义是不允许的；然而，汇编语言的程序可没有 extern 机制，如果一个汇编语言程序定义了 main 函数，那么所有与之链接的C程序都不能定义 main 函数。不像 PHP 中每个作用域都有一个动态的符号表，目标文件中的符号表只能有一个，而且必须在编译时确定。为此，UNIX 下的C语言规定所有全局符号名前加上下划线，称为符号修饰；目前 MSVC 保留着这个传统，而 GCC 默认已经去掉了。然而，在C++语言中，符号管理就没有这么简单了。首先，C++允许多个不同参数类型的函数拥有一样的名字，这要求修饰后的符号名反映参数的类型信息；其次，不同的命名空间、类中可以有同名符号，这要求修饰后的符号名反映命名空间、类的信息。具体的符号修饰策略就见仁见智了。

了解了目标文件的格式，前面的链接机制还要完善几处细节：

弱符号在 ELF 文件的符号表中 “符号所在段” 设为 SHN_COMMON。与之对应，在当前 ELF 文件中未定义的符号设为 SHN_UNDEF，包含绝对的值的符号（包括强符号、文件名等）设为 SHN_ABS。

符号的定义有强弱，那么符号的引用呢？GCC 还提供了 “弱引用” 机制，在符号声明前加入

1

__attribute__((weakref))

关键字，则如果该符号未定义，GCC将不报错，而用一个特殊值（0）替代之，程序将有机会在不提供此功能的情况下运行，而不是无法链接成功，使得程序的功能更便于裁剪和组合。

弱引用在ELF文件的符号表中“符号绑定信息”设为 STB_WEAK。与之对应，对目标文件外部可见（如使用 extern 声明的）全局符号设为 STB_GLOBAL，对外不可见的局部符号设为 STB_LOCAL。