2011年七月月 发布的文章

也谈共享库2

我之前写过一篇名为"也谈共享库"的博文,对共享库的查找和符号解析机制做了还算比较详细的说明,不过百密一疏,总有一些意想不到的情况发生。这不今天我又遇到了一个有关共享库的新问题,这里将这个问题及其解决过程记录下来,也算是对上一篇文章中未涉及内容的一个补充吧。

N年前我曾参与过部门的一个可复用系统的设计开发,当时我们设计了一种插件式的系统结构,其中所谓的"插件"是以共享库的形式提供。主程序通过读取配置,获取插件的位置,并在运行期利用dlopen动态加载插件(.so文件),用dlsym查找、绑定并执行.so中的特定业务函数。

我们可以用下面样例代码简单地模拟出这种设计:

/*
 * 主程序 main.c */
 * 需include dlfcn.h、link.h等标准头文件,这里省略
 */
typedef int (*PLUGIN_MAIN_FUNC)(void);

int main() {
        void *handle = NULL;
        char *dso = "plugin.so";
        char *func_name = "plugin_main";
        PLUGIN_MAIN_FUNC func = NULL;

        handle = dlopen(dso, RTLD_LAZY);
        if (handle == NULL) {
                printf("dlopen (%s)失败!\n", dso);
                return -1;
        }

        func = dlsym(handle, func_name);
        if (func == NULL) {
                printf("dlsym (%s)失败!\n", func_name);
                return -1;
        }

        printf("%d\n", my_add(4, 8));
        printf("%d\n", func());

        dlclose(handle);
        return 0;
}

以下my_add接口可以理解为主程序所使用的底层库,亦可为plugin程序使用。

/* add.h */
int my_add(int a, int b);

/* add.c */
int my_add(int a, int b) {
       return a + b;
}

/* 以下是plugin.so的源代码 */
/* plugin.c */
#include "add.h"

int plugin_main() {
        return my_add(5, 6);
}

在Solaris 10 for x86, Gcc 3.4.6下编译plugin和主程序:
$ gcc -fPIC -shared -o plugin.so plugin.c
$ gcc -o main main.c add.c -ldl

执行main,我们得到了期望的结果:
12
11

将该样例拿到Solaris 10 for sparc平台上编译运行一样没有问题。最后,我把源代码拿到了我的Ubuntu 10.04下,Gcc的版本是4.4.3,编译过程很顺利,但是执行的结果却与预期不符,执行main后得到的结果是:
12
main: symbol lookup error: ./plugin.so: undefined symbol: my_add

居然提示无法找到符号my_add!在Solaris上明明可以正确执行的程序,搬到Linux下却出错。这种问题十分对我的胃口,开始“破案”^_^。

我们先来收集证据,先看看plugin.so的符号表:

$ nm -f sysv plugin.so

Name                  Value   Class        Type         Size     Line  Section
… …
my_add              |        |   U  |            NOTYPE|        |     |*UND*
plugin_main         |0000046c|   T  |              FUNC|0000002c|     |.text

my_add符号的确是Undefined(未定义)的,也就是说在主程序获得my_add符号并准备执行时(注意我们在dlopen的参数中使用了RTLD_LAZY),加载器需要在此时为my_add这个符号寻找其定义。main这个可执行文件中是定义了这个符号的,我们可以通过nm命令看到这一情况:

$ nm -f sysv main

Name                  Value   Class        Type         Size     Line  Section
… …
main                |080484f4|   T  |              FUNC|000000ee|     |.text
my_add              |080485e4|   T  |              FUNC|0000000e|     |.text

按照我原先的理解,加载器在为my_add符号寻找定义时,是应该可以将main中的my_add定义与之相绑定的,但是事实却是加载器无法找到my_add这个符号的定义,导致执行出错。

你也许会立刻想出一种解决方法,将add.c与plugin.c一起编译:
$ gcc -fPIC -shared -o plugin.so plugin.c
这样编译后的plugin.so中的确有了my_add的定义:

$ nm -f sysv plugin.so
Name                  Value   Class        Type         Size     Line  Section
… …
my_add              |00000498|   T  |              FUNC|0000000e|     |.text
plugin_main         |0000046c|   T  |              FUNC|0000002c|     |.text

main也可以正确执行了。但这显然不是我么想要的结果。作为一个plugin,其编译时很可能无法得到add.c或者add.c对应的静态库,也许只能得到add.h,所以这种方法很局限。另外这个方案也在plugin源码与主程序源码之间无端建立一个耦合,导致后续的一些不方便。

接下来,我使用readelf工具对main的ELF格式做了一次全面检查:
$ readelf -a main

在readelf输出的内容中,我发现了两个“符号表(Symbol table)”:

Symbol table '.dynsym' contains 9 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
   … …
     3: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlclose@GLIBC_2.0 (2)
     4: 00000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.0 (3)
     5: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlsym@GLIBC_2.0 (2)
     6: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlopen@GLIBC_2.1 (4)
     7: 00000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.0 (3)
   … …

Symbol table '.symtab' contains 70 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
   … …
    52: 080485e4    14 FUNC    GLOBAL DEFAULT   14 my_add
    54: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlclose@@GLIBC_2.0
    55: 00000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@@GLIBC_
    58: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlsym@@GLIBC_2.0
    60: 00000000     0 FUNC    GLOBAL DEFAULT  UND dlopen@@GLIBC_2.1
    63: 00000000     0 FUNC    GLOBAL DEFAULT  UND printf@@GLIBC_2.0
    68: 080484f4   238 FUNC    GLOBAL DEFAULT   14 main
   … …

仔细观察一下这两个表,你会发现有些函数是重复的,如dlopen在两个表里面都有,但my_add却只在.symtab中出现。也许问题就在这里。迅速翻阅了一些资料(比如"Linkers and Loaders"),发现这两个符号表的功用确有不同。

.symtab中的符号也称为normal symbol,表中包含了所有ELF文件中涉及的所有符号,用于普通的链接器;.dynsym中的符号则是由未定义的动态链接符号以及该ELF文件本身导出(export)的用于动态链接的符号组成。说到这里,头绪渐渐明晰。在本例中,.symtab这个普通符号表中虽然包含了my_add符号,但是这并不能说明my_add是main导出的用于动态链接的符号(dynamic symbol),只有my_add出现在.dynsym中时,加载器才能在符号查找时看到my_add,而本例中my_add恰恰没有出现在.dynsym表中。

使用nm -D命令,我们也可以查看.dynsym符号表:
$ nm -D -f sysv main

Symbols from main:

Name                  Value   Class        Type         Size     Line  Section
… …
dlclose             |        |   U  |              FUNC|        |     |*UND*
dlopen              |        |   U  |              FUNC|        |     |*UND*
dlsym               |        |   U  |              FUNC|        |     |*UND*
… …

让我奇怪的是为何在Solaris上main的执行是没有问题的呢,换到Solaris下,我们同样使用nm -D查看上面的main文件:

$ nm -D main
main:

[Index]   Value      Size    Type  Bind  Other Shndx   Name

[10]    | 134547364|     305|FUNC |GLOB |0    |10     |main
[19]    | 134547353|      11|FUNC |GLOB |0    |10     |my_add

从结果可以看出,Solaris上main文件的.dynsym符号表中是包含了my_add符号的,这也就是main在Solaris上可以正常执行的原因。

难道与Gcc版本有关系?Solaris上的Gcc是3.4.6,而我的Ubuntu上的Gcc是4.4.3。"Binary Hacks"一书中曾提到使用-rdynamic选项可为可执行文件留下可用于动态连接的符号。向gcc传入-rdynamic,则链接器会得到-export-dynamic选项。我在Ubuntu下试一下这个选项:

$ gcc -o main main.c add.c -ldl -rdynamic
$ main
12
11

问题果然解决了。我们再用nm -D查看一下这个新版main文件:
$ nm -D -f sysv main
Symbols from main:

Name                  Value   Class        Type         Size     Line  Section
… …
dlsym               |        |   U  |              FUNC|        |     |*UND*
main                |080486e4|   T  |              FUNC|000000ee|     |.text
my_add              |080487d4|   T  |              FUNC|0000000e|     |.text

果然,.dynsym表扩大了好多,my_add也出现在了该表中,这样在main执行时加载器就可以为plugin.so中的my_add符号绑定到其定义了。

我在Solaris下的gcc命令行上也增加-rdynamic选项,但编译后得到的结果却是:
gcc: unrecognized option `-rdynamic'

查看了Gcc官方的Manual后发现,在Gcc 4.1.2版本之前的Manual中都无法找到-rdynamic这一选项,也就是说这个选项是后加入Gcc中的。之前我们看到Solaris上main文件的dynsym表默认就包含了my_add,而4.1.2版本后的Gcc则默认不将自定义的全局函数导出。这是为什么呢?也许是为了提升可执行程序动态链接的性能,这个性能估计与dynsym表的大小不无关系。表越小,需要动态链接的符号越少,符号解析和绑定的速度也就越快;同时由于该表的内容需要在执行时加载到内存,这样表越小,加载的时间以及内存的占用也都很少,所以GCC更改了策略,默认选择不导出自定义的全局符号,并提供-rdynamic让程序员选择是否导出已定义的符号用于动态链接。

也谈C语言编译器的标准编译阶段

了解C编译器的工作流程有助于C程序员解决编译代码过程中出现的问题。市面上凡是讲解得还算全面的C语言书籍中都或多或少对此有所提及。

让我们在这里来回顾一下C编译器的工作流程!一般C编译器的工作流程大致分为:预编译、编译、生成目标代码(汇编)和连接这四个主要步骤。我们用实例具体描述一下这四个步骤,以最著名的GCC编译器结合helloworld.c文件为例:

/* helloworld.c */
int main() {
    printf("hello, world\n");
    return 0;
}

使用Gcc编译该源文件,我们看到编译器有如下输出(省略了一些内容):

$ gcc -v -o helloworld helloworld.c
… …
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
COLLECT_GCC_OPTIONS='-v' '-o' 'helloworld' '-mtune=generic' '-march=i486'

 /usr/lib/gcc/i486-linux-gnu/4.4.3/cc1 -quiet -v helloworld.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase helloworld.c -mtune=generic -march=i486 -auxbase helloworld -version -fstack-protector -o /tmp/ccgoLMLQ.s
… …

COLLECT_GCC_OPTIONS='-v' '-o' 'helloworld' '-mtune=generic' '-march=i486'
 as -V -Qy -o /tmp/ccN9HVdH.o /tmp/ccgoLMLQ.s
… …

COLLECT_GCC_OPTIONS='-v' '-o' 'helloworld' '-mtune=generic' '-march=i486'
 /usr/lib/gcc/i486-linux-gnu/4.4.3/collect2 –build-id –eh-frame-hdr -m elf_i386 –hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o helloworld -z relro /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.4.3/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.4.3 -L/usr/lib/gcc/i486-linux-gnu/4.4.3 -L/usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.4.3/../../.. -L/usr/lib/i486-linux-gnu /tmp/ccN9HVdH.o -lgcc –as-needed -lgcc_s –no-as-needed -lc -lgcc –as-needed -lgcc_s –no-as-needed /usr/lib/gcc/i486-linux-gnu/4.4.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.4.3/../../../../lib/crtn.o

可以明显看出,Gcc的输出大致分为三段:
首先是调用/usr/lib/gcc/i486-linux-gnu/4.4.3/cc1对源文件helloworld.c进行预编译和编译,生成汇编代码文件/tmp/ccgoLMLQ.s;
然后,汇编器as被启动,编译ccgoLMLQ.s,生成目标代码文件/tmp/ccN9HVdH.o;
最后,链接器collect2将目标文件和一些库文件连接在一起,形成可执行程序helloworld。

简单总结一下就是:
- cc1负责预编译源代码helloworld.c,生成helloworld.i(指代预编译后生成的中间文件,很多编译器为了效率并不使用临时文件,而使用管道等方法),我们可以通过gcc -E helloworld.c > helloworld.i得到helloworld.i这个文件;
- cc1将helloworld.i作为输入,对预编译后的源文件进行编译,生成汇编代码文件helloworld.s(指代编译后的汇编代码文件)。我们可以通过gcc -S helloworld.c得到helloworld.s文件;
- as负责根据helloworld.s生成目标代码文件helloworld.o,我们可以通过gcc -c helloworld.c来获得helloworld.o;
- collect2负责将目标代码与各种库文件连接,形成最终可执行文件helloworld。

其实以上不是这次重点要谈的。粗略了解了以上流程的确有助于解决编译过程中的问题,但是还不能解决全部,你需要了解更多。关于链接过程,我在博客里曾多次谈过,这里就不说了。as执行的汇编过程基本不会出现问题,这里也不谈,我们这次重点要关注的就是C编译器在预编译和编译过程中的一些细节。

C标准(C99)在5.1.1.2小节将C编译器工作流程分成了八个标准阶段,我这里也是结合这八个阶段并按照我的理解做进一步的解释的。在开始之前我们要明确下面这八个阶段中的前七个都是针对一个编译单元/翻译单元的,自始至终你都要牢记这一点。

第一阶段:物理源文件中的多字节字符被映射到源字符集(具体以何种字符编码方式映射与编译器的实现相关)。三字符序列(或称为三字符组)被替换为相应的单字符的内部表示。

标准中的语言总是那么绕口。这里主要说的是编译器读取物理源文件的内容,此时编译器并不知道该源文件中的多字节字符采用的是何种字符集编码方式。以GCC为例,GCC默认源码文件多字节字符的编码为utf8,而GCC其作为内部表示的源字符集默认也是utf8,所以默认情况下,这个阶段GCC不会对源文件中的内容做任何转换。

例如我们有一个内码格式为GBK的名为foo.c的文件:
/* foo.c */
int main() {
    printf("中国\n");
}

按照GBK码表,其中的字符串常量"中国"的编码为d6 d0 b9 fa。将该文件传到一个locale为utf8的平台上编译,我们发现GCC并未尝试将GBK转换为其内部表示的编码格式utf8:
$ gcc -E foo.c > foo.i
$ od -x foo.i
我们可以看到foo.i中"中国"二个字的编码依旧为d6 d0 b9 fa。

不过我们可以显式告知编译器源码文件的编码格式,如果其所在OS支持从该编码格式到utf8的转换,则GCC会在第一阶段就进行这个转换:
$ gcc -E foo.c > foo.i -finput-charset='gbk'
这次foo.i中的"中国"二字的编码变成了utf编码:e4 b8 ad e5 9b bd

三字符序列(trigraphs)的替换过程也是在第一阶段进行的,也就是发生在词法分析之前以及识别字符常量和字符串常量中的转义字符之前。我们看看这个例子:
/* trigraphs_test.c */
int main(int argc, const char *argv[]) {
    printf("hello??/n");
    printf("world\n");
    return 0;
}

$ gcc -E trigraphs_test.c > trigraphs_test.i -std=c99

可以看到trigraphs_test.i内容为:
int main(int argc, const char *argv[]) {
    printf("hello\n");
    printf("world\n");
    return 0;
}

三字符序列发生在转义之前,所以printf("hello??/n");在字符串转义过程之前就先进行了三字符序列的替换(否则编译器会报错),替换成了printf("hello\n");后续在字符串常量转义字符时\n才被当作了换行符处理。

第二阶段:这个阶段比较简单,说白了就是去掉续行符,即所有相邻的'\'和'\n'的组合,将物理源代码的行拼接为逻辑源代码行。

第三阶段:源文件被分解为预处理词法元素(tokens)和空白字符序列(包括注释)。源文件不应该以一个部分预处理词法元素或部分注释结束(例如一个注释不能一半在一个文件中,而另一半在接下来的文件中)。每条注释都被替换成一个空格字符。换行符保留。将非空空白字符序列(诸如空格、TAB键等,除了换行符)保留还是替换为一个空格字符则由编译器的实现决定

这个阶段中预处理器开始执行了词法分析,删除不必要字符,转换字符,为后续处理营造一个干净的环境。

第四阶段:预处理指示符被执行,宏调用被扩展,_Pragma一元操作符表达式被执行。对通用字符名(UCN)进行词法元素连接的行为是未定义的。预处理器从阶段1到阶段4递归地处理源文件中#include预处理指示符中的头文件或源文件。最后所有预处理指示符被删除。

这个阶段预处理器是主力,其结果是我们得到了一个包含了诸多头文件内容的预处理后的编译单元文件,用作后续处理的输入。

第五阶段:字符常量、字符串常量中的源字符集字符或转义字符序列都会被转换为相应的执行字符集中的字符;如果执行字符集中没有对应的字符(除了宽字符null),则转换成什么由编译器的实现确定。

注意与第一阶段不同的是:这个是在foo.i的基础上,也就是说在GCC默认foo.i中的字符都是utf8的基础上,将代码中的字符常量以及字符串常量中的源字符集字符(默认utf8)转换为执行字符集(默认也是utf8),包括通用字符名(UCN)。

注意UCN也可以看成转义字符序列,在这个阶段被转换为执行字符集,如:
char *a = "\u4e2d\u56fd"; /* 两个ucn字符为'中国' */

我们通过gcc -S得到源文件对应的.s汇编文件,从汇编文件内容可以看到a的内部表示为:
.string "\344\270\255\345\233\275"
即utf编码的'中国'。

另外这里说的字符和字符串串常量,也包括宽字符和宽字符串,其转换为内部表示的过程也在这个阶段进行,例如下面代码:
wchar w[] = L"中国";

该代码进行了一次utf8到宽字符内部表示(GCC为unicode32)的转换。

第六阶段:将相邻两个字符串字面元素连接起来
这个阶段用一个例子就能说明问题,很简单:
char *a = "hello"
          " world";

经过编译后,我们可以看到.s文件中关于a的定义:
.string "hello world"

这就相当于将"hello"和" world"连接起来,形成"hello world"。

第七阶段:编译器执行词法分析、语法分析以及语义分析,生成该编译单元对应的目标代码(.o文件)。
第八阶段:Resolve所有外部符号(包括变量和函数),并将诸多编译单元的.o以及外部库连接成可执行程序。

个人感觉编译阶段中的难点就是几个涉及字符集转换的阶段,如第一个阶段和第五个阶段,不过只要弄清楚编译器是如何做的,相信所有编译问题都可以被轻松解决了。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! 图片广告位1 图片广告位2 图片广告位3 商务合作请联系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

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats