共享库中的符号链接
清晨，部门新来的一位小兄弟打来求助电话，说是系统启动的时候出现类似："ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到"的错误。这个系统是05年开发的一个复用度很高的自研产品，后续项目只需在其基础上做少量二次开发工作即可满足新功能的要求。为了做到一定的通用性，我们使用了类似插件的框架，这样系统在启动的时候会根据配置加载一些'共享库'(.so文件)，而这个小同事反映的问题就出在这。
上面仅仅是一个引子，在写下本篇文章之前，这个问题已经被解决，我的那个小同事在连续奋战14个小时(从昨晚21:00到今天上午11:00)后，终于也可以安心踏上返回四川老家的火车了。事后，我深入的想了一下这个问题，觉得有必要说一下。
这里用一个简单的例子来重现一下这个问题吧。我们先来准备一个静态链接库(.a)和一个动态共享库(.so)，都比较简单，能反映出问题就行。
[静态库]
//teststatic.h
int static_add(int a, int b);
//teststatic.c
#include "teststatic.h"
int static_add(int a, int b) {
return a+b;
}
编译静态库：
gcc -c teststatic.c
ar crv libteststatic.a teststatic.o
[动态共享库]
//testshared.h
int dynamic_add(int a, int b);
//testshared.c
#include "testshared.h"
#include "teststatic.h"
int dynamic_add(int a, int b) {
return static_add(a, b);
}
编译共享库：
gcc testshared.c -fPIC -shared -o libtestshared.so
然后，我们再写一个测试桩程序，其主要功能就是：通过dlopen和dlsym在运行时动态加载libtestshared.so，然后得到符号dynamic_add的地址，完成计算功能。
#include
#include
typedef int (*PTR)(int, int);
int main() {
void *handle = NULL;
char *errinfo = NULL;
PTR ptr;
int rv;
handle = dlopen("./libtestshared.so", RTLD_LAZY);
if (handle == NULL) {
errinfo = dlerror();
printf("dlopen失败: %s\n", errinfo);
return;
}
ptr = (PTR)dlsym(handle, "dynamic_add");
if (ptr == NULL) {
errinfo = dlerror();
printf("dlsym失败: %s\n", errinfo);
return;
}
rv = ptr(1,2);
printf("rv = %d\n", rv);
}
编译：gcc -o testmain testmain.c -ldl -L./ -lteststatic
运行结果：ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到，被杀掉。
通过运行结果分析：程序在启动时，链接程序并没有找到符号:static_add，无从知道其指令代码，所以报错。这个例子反映的就是我那个小同事犯的'错误'– 程序在加载阶段链接器无法resolve共享库里调用的其他函数符号。那为什么找不到呢？我们还需简单回顾一下程序启动阶段的一些事情。
程序启动后，由加载器(即常说的loader)将之加载到内存中，过程很复杂和繁琐，我们就说程序中的符号是如何resolved的(我是从John R.Levine的"Linkers & Loaders"一书中学到的一些皮毛)。加载阶段，加载器(很多工作由链接器完成)先进行自身的初始化，之后它会根据程序文件的头(Headers)中的信息，查找程序所需要的共享库(静态库是在编译期间就已经链接到程序本身中了)的名字，对于每一个共享库的名字，它都会在搜索路径下搜索该共享库是否存在，如果存在，则处理该共享库文件，处理包括：分配text和data段空间并进行映射，其符号表将被merge到主符号表里；如果该共享库文件依然有依赖的其他共享库，且该依赖的共享库在之前并未被load，则将该依赖的共享库加入到待加载的库列表中。
有人要说，上面的testmain程序与这个加载过程不同啊，testmain是用dlopen和dlsym在运行时而不是加载时加载.so的，其实按照John R.Levine的说法: "The two routines dlopen & dlsym are actually simple wrappers that call back into the dynamic linker"，也就是说：使用dlopen和dlsym的组合时，完成的事情和加载阶段链接器完成的事情是一样的。
那我们来看，testmain编译的时候是不依赖任何显式(C运行时和unix系统库等隐式的除外)的共享库的，那么在加载libtestshare.so时，遇到static_add这个符号时，就不知所措了。这里又有人要问了：编译testmain的时候不是链接了libteststatic.a这个库了吗，这个库里不是有static_add的符号吗？你可以nm testmain > dump.log看一下，看看dump.log中是否有static_add这个符号。其实细想一下也会知道：testmain.c中根本没有使用static_add，编译器当然不会无端将static_add的放入testmain的可执行文件中了，否则在unix系统下的每个用户级程序的'体格'都会极其庞大。
上面说过，因为testmain.c中没有使用static_add，所以不能动态加载so时，不能resolve这个符号，如果testmain.c中使用了static_add，那么程序就没有问题了吧？没错！看下面：
#include "teststatic.h"
… …
int main() {
void *handle = NULL;
char *errinfo = NULL;
PTR ptr;
int rv;
rv = static_add(5, 6);
printf("rv = %d\n", rv);
… …
rv = ptr(1,2);
printf("rv = %d\n", rv);
}
这样一来，static_add就会体现在testmain的符号表里，作为testmain的一部分了。当运行时加载.so后，遇到static_add这个符号时，链接器就有据可依了。
又会有人问：我们不能要求所有.so中出现的符号在主程序中都要有吧？对，这样要求显然是无理的，那么如何是好呢？我们只能在编译.so时将这些符号静态链入.so，比如：gcc testshared.c -fPIC -shared -o libtestshared.so -L./ -lteststatic
我们可以通过nm命令看到链入静态库前后的不同：
未链入静态库时nm *.so，符号static_add处于UNDEF状态
[67] | 0| 0|NOTY |GLOB |0 |UNDEF |static_add
链入静态库后，nm *.so的结果：
[68] | 1412| 36|FUNC |GLOB |0 |10 |static_add
static_add的代码被copy一份放到了.so中。
这里关于dlopen函数的第二个参数mode再多写两句。上面的例子中，我们传入的参数是RTLD_LAZY，什么意思呢？RTLD_LAZY是说：.so中的符号只有在其第一次使用的时候，才会由链接器计算出其实际地址，否则在.so加载时是不计算其实际地址的。原因也很简单：一个.so文件中可能有成百上千的符号，我们的程序也许只用到其中的一两个，如果加载时所有符号都要将其实际地址映射好，显然会降低运行时动态加载的性能。还是以testmain.c为例，如果代码中去掉对ptr(1,2)的调用，那么执行testmain是不会出错的。
dlopen中还提供了些许选项，比如：RTLD_NOW，从字面含义也可以猜测出来，其含义与RTLD_LAZY正相反，即.so加载时，其内部所有符号都要计算出实际地址。还以testmain.c为例：
handle = dlopen("./libtestshared.so", RTLD_NOW);
这时即使去掉对ptr(1,2)的调用，执行时会提示：dlopen失败: ld.so.1: testmain: 致命的: 重定位错误: 文件./libtestshared.so: 符号static_add: 参照的符号没有找到。
看来，共享库中的符号链接没有想象中的那么容易，使用的时候要'小心'。也许正是这些需要你投入和认真思考的问题才让使用C语言进行底层或系统开发更具魅力。
评论