标签 构建 下的文章

共享库中的符号链接

清晨,部门新来的一位小兄弟打来求助电话,说是系统启动的时候出现类似:"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语言进行底层或系统开发更具魅力。

也谈’SIGBUS和SIGSEGV’

SIGBUS和SIGSEGV也许是我们在平时遇到的次数最多的两个内存错误信号。内存问题一直是最令我们头疼的事情,弄清楚两个信号的发生缘由对我们很好的理解程序的运行是大有裨益的。

我们来看两段程序:
//testsigsegv.c
int main() {
        char *pc = (char*)0×00001111;
        *pc = 17;
}

//testsigbus.c
int main() {
        int *pi = (int*)0×00001111;
        *pi = 17;
}

上面的代码那么的相似,我们也同样用gcc编译(加上-g选项,便于gdb调试;平台Solaris Sparc),执行结果也都是dump core。但通过GDB对core进行观察,你会发现细微的不同。第一个例子出的core原因是:Program terminated with signal 11, Segmentation fault. 而第二个例子的core则提示:Program terminated with signal 10, Bus error. 两者有什么不同呢?这两段代码的共同点都是将一个非法地址赋值给指针变量,然后试图写数据到这个地址。

如果要说清楚这个问题,我们就要结合汇编码和一些计算机的体系结构的知识来共同分析了。

先来看testsigsegv.c的汇编码:
… …
main:
        !#PROLOGUE# 0
        save    %sp, -120, %sp
        !#PROLOGUE# 1
        sethi   %hi(4096), %i0
        or      %i0, 273, %i0
        st      %i0, [%fp-20]
        ld      [%fp-20], %i1
        mov     17, %i0
        stb     %i0, [%i1]
        nop
        ret
        restore
… …

我们关注的是这句:stb     %i0, [%i1]
从计算机底层的执行角度来说,过程是如何的呢?%i0寄存器里存储的是立即数17,我们要将之存储到寄存器%i1的值指向的内存地址。这一过程对于CPU来说其指挥执行的正常过程是:将寄存器%i0中的值送上数据总线,将寄存器%i1的值送到地址总线,然后使能控制总线上的写信号完成这一向内存写1 byte数据的过程。

我们再看testsigbus.c的汇编码:
… …
main:
        !#PROLOGUE# 0
        save    %sp, -120, %sp
        !#PROLOGUE# 1
        sethi   %hi(4096), %i0
        or      %i0, 273, %i0
        st      %i0, [%fp-20]
        ld      [%fp-20], %i1
        mov     17, %i0
        st      %i0, [%i1]
        nop
        ret
        restore
… …

同样最后一句:st      %i0, [%i1],CPU执行的过程与testsigsegv.c中的一致(只是要存储数据长度是4字节),那为什么产生错误的原因不同呢?一个是SIGSEGV,而另一个是SIGBUS。这里涉及到的就是对内存地址的校验的问题了,包括对内存地址是否对齐的校验以及该内存地址是否合法的校验。

我们假设如果首先进行的内存地址是否合法的校验(是否归属于用户进程的地址空间),那么我们回顾一下,这两个程序中的地址0×00001111显然都不合法,按照这种流程,两个程序都应该是SIGSEGV导致的core才对,但是事实并非如此。那难道是先校验内存地址的对齐?我们再看这种思路是否合理?

testsigsegv.c中,0×00001111这个地址值被赋给了char *pc;也就是告诉CPU通过这个地址我们要存取一个字节的值,对于一个字节长度的数据,无所谓对齐,所以该地址通过对齐校验;并被放到地址总线上了。而在testsigbus.c里,0×00001111这个地址值被赋给了int *pi;也就是告诉CPU通过这个地址我们要存取一个起码4个字节的值,那么对于长度4个字节的对象,其存放地址起码要被4整除才可以,而0×00001111这个值显然不能满足要求,也就不能通过内存对齐的校验。也就是说SIGBUS这个信号在地址被放到地址总线之后被检查出来的不符合对齐的错误;而SIGSEGV则是在地址已经放到地址总线上后,由后续流程中的某个设施检查出来的内存违法访问错误。

一般我们平时遇到SIGBUS时总是因为地址未对齐导致的,而SIGSEGV则是由于内存地址不合法造成的。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats