C语言中的强符号与弱符号

转自：http://blog.csdn.net/astrotycoon/article/details/8008629

 

一、概述

在C语言中，函数和初始化的全局变量（包括显示初始化为0）是强符号，未初始化的全局变量是弱符号。

对于它们，下列三条规则使用：

① 同名的强符号只能有一个，否则编译器报"重复定义"错误。

② 允许一个强符号和多个弱符号，但定义会选择强符号的。

③ 当有多个弱符号相同时，链接器选择占用内存空间最大的那个。

二、哪些符号是弱符号？

我们经常在编程中碰到一种情况叫符号重复定义。多个目标文件中含有相同名字全局符号的定义，那么这些目标文件链接的时候将会出现符号重复定义的错误。比如我们在目标文件A和目标文件B都定义了一个全局整形变量global，并将它们都初始化，那么链接器将A和B进行链接时会报错：

1 b.o:(.data+0x0): multiple definition of `global'
2 a.o:(.data+0x0): first defined here

这种符号的定义可以被称为强符号（Strong Symbol）。有些符号的定义可以被称为弱符号（Weak Symbol）。对于C语言来说，编译器默认函数和初始化了的全局变量为强符号，未初始化的全局变量为弱符号(C++并没有将未初始化的全局符号视为弱符号)。我们也可以通过GCC的"__attribute__((weak))"来定义任何一个强符号为弱符号。注意，强符号和弱符号都是针对定义来说的，不是针对符号的引用。比如我们有下面这段程序：

extern int ext;
int weak1;
int strong = 1;
int __attribute__((weak)) weak2 = 2;

int main()
{
        return 0;
}

上面这段程序中，"weak"和"weak2"是弱符号，"strong"和"main"是强符号，而"ext"既非强符号也非弱符号，因为它是一个外部变量的引用。

 

下面一段话摘自wikipedia：

In computing, a weak symbol is a symbol definition in an object file or dynamic library that may be overridden by other symbol definitions. Its value will be zero if no definition is found by the loader.

换句话说，就是我们可以定义一个符号，而该符号在链接时可以不解析。

让我们再看一些例子：

$ cat err.c
int main(void)
{
        f();
        return 0;
}

很明显，不能编译通过，因为'undefined reference' ：

$ gcc err.c
/tmp/ccYx7WNg.o: In function `main':
err.c:(.text+0x12): undefined reference to `f'
collect2: ld returned 1 exit status

那么，如果将符号f声明成弱符号，会怎么呢？

$ cat weak.c
void __attribute__((weak)) f();
int main(void)
{
        if (f)
        f();
        return 0;
}
$ gcc weak.c

居然编译通过了，甚至成功执行！让我们看看为什么？

首先声明了一个符号f()，属性为weak，但并不定义它，这样，链接器会将此未定义的weak symbol赋值为0，也就是说f()并没有真正被调用，试试看，去掉if条件，肯定core dump！

我们可以通过nm来查看符号：

$ nm a.out
...
w f
08048324 T main
...

如果我们在另一个文件中定义函数f，与week.c一起编译链接，那么函数f就会正确的被调用！

$ cat f.c
#include <stdio.h>
void f(void)
{
        printf("hello from f\n");
}

$ gcc -c weak.c f.c
$ gcc -o weak weak.o f.o
$ ./weak
hello from f

$ nm weak.o
w f
00000000 T main
$ nm f.o
00000000 T f
U puts
$ nm weak
...
08048384 T f
08048354 T main
U puts@@GLIBC_2.0
...

我们甚至可以定义强符号来override弱符号：

$ cat orig.c
#include <stdio.h>
void __attribute__((weak)) f()
{
        printf("original f..\n");
}
int main(void)
{
        f();
        return 0;
}
$ gcc orig.c
$ ./a.out
original f..

$ cat ovrd.c
#include <stdio.h>
void f(void)
{
        printf("overridden f!\n");
}
$ gcc -c orig.c ovrd.c
$ gcc -o ovrd orig.o ovrd.o
$ ./ovrd
overridden f!

$ nm orig.o
00000000 W f
00000014 T main
U puts
$ nm ovrd.o
00000000 T f
U puts
$ nm ovrd
...
0804838c T f
08048368 T main
U puts@@GLIBC_2.0
...

或者如下：

$ cat orig-obj.c
#include <stdio.h>
int __attribute__((weak)) x = 1;
int __attribute__((weak)) y = 1;
int main(void)
{
        printf("x = %d, y = %d\n", x, y);
        return 0;
}
$ gcc orig-obj.c
$ ./a.out
x = 1, y = 1

$ cat ovrd-obj.c
int x = 2;
void f(void)
{
}
$ gcc -c orig-obj.c ovrd-obj.c
$ gcc -o ovrd-obj orig-obj.o ovrd-obj.o
$ ./ovrd-obj
x = 2, y = 1

$ nm orig-obj.o
00000000 T main
U printf
00000000 V x
00000004 V y
$ nm ovrd-obj.o
00000000 T f
00000000 D x
$ nm ovrd-obj
...
08048394 T f
08048354 T main
U printf@@GLIBC_2.0
080495c8 D x
080495c4 V y
...

 

那么当出现multiple symbols时，会如何呢？

$ cat mul.c
int main(void)
{
        f();
        return 0;
}
$ cat s1.c
#include <stdio.h>
void f(void)
{
        printf("1st strong f from %s\n", __FILE__);
}
$ cat s2.c
#include <stdio.h>
void f(void)
{
        printf("2nd strong f from %s\n", __FILE__);
}
$ cat w1.c
#include <stdio.h>
void __attribute__((weak)) f(void)
{
        printf("1st weak f from %s\n", __FILE__);
}
$ cat w2.c
#include <stdio.h>
void __attribute__((weak)) f(void)
{
        printf("2nd weak f from %s\n", __FILE__);
}
$ gcc -c mul.c s1.c s2.c w1.c w2.c

$ gcc -o test1 mul.o s1.o s2.o
s2.o: In function `f':
s2.c:(.text+0x0): multiple definition of `f'
s1.o:s1.c:(.text+0x0): first defined here
collect2: ld returned 1 exit status


$ gcc -o test2 mul.o s1.o w1.o w2.o
$ ./test2
1st strong f from s1.c


$ gcc -o test3-1 mul.o w1.o w2.o
$ ./test3-1
1st weak f from w1.c
$ gcc -o test3-2 mul.o w2.o w1.o
$ ./test3-2
2nd weak f from w2.c

关于最后一个例子，我想补充的是：如果我们改变给出的编译顺序会怎么样呢？比如像下面这样编译：

$ gcc -o test2 mul.o w1.o s1.o w2.o
$ ./test2
1st strong f from s1.c

看，我将w1.o放在最前面，不过链接器依然选择强符号，这是我们所期望的。

 

不过，如果我们这样做：

$ ar qs libw.a w1.o w2.o
$ ar qs libs.a s1.o s2.o

再编译：

$ gcc -o test2 mul.o -L. -lw -ls
$ ./test2
1st weak f from w1.c

再改成这样编译：

$ gcc -o test2 mul.o -L. -ls -lw
$ ./test2
1st strong f from s1.c

看，情况有变！这是为什么？

原因就是GCC（准确地说是链接器）对待库是不一样的 —— 默认的，链接器使用第一个找到的符号，后面的就不搜索了。

不过我们也可以强制链接器搜索所有的库，办法如下：

$ ar qs libw.a w1.o w2.o
$ ar qs libs.a s1.o s2.o
$ gcc -o test2 mul.o -L. -Wl,--whole-archive -lw -ls -Wl,--no-whole-archive
./libs.a(s2.o): In function `f':
s2.c:(.text+0x0): multiple definition of `f'
./libs.a(s1.o):s1.c:(.text+0x0): first defined here
collect2: error: ld returned 1 exit status

重新如下操作：

$ rm libw.a libs.a
$ ar qs libw.a w1.o w2.o
$ ar qs libs.a s1.o
$ gcc -o test2 mul.o -L. -Wl,--whole-archive -lw -ls -Wl,--no-whole-archive
$ ./test2
1st strong f from s1.c

现在可以了，尽管-lw在前！
 

 让我们再来看一个具体的例子：

 

// main.c
#include <stdio.h>
#include <stdlib.h>

extern int fun(void);

int global_var1 = 0xff00ff00;       // 强符号
int global_var2 = 0x00ff00ff;       // 强符号

int main(int argc, const char *argv[])
{
/////////////////////////////////////////////////////////////////////
    printf("in main.c: &global_var1 = %p", &global_var1);
    printf(" global_var1 = %x\n", global_var1);
    printf("sizeof(global_var1) = %d\n", sizeof(global_var1));
/////////////////////////////////////////////////////////////////////
    printf("in main.c: &global_var2 = %p", &global_var2);
    printf(" global_var2 = %x\n", global_var2);
    printf("sizeof(global_var2) = %d\n", sizeof(global_var2));
/////////////////////////////////////////////////////////////////////
    fun();

    printf("global_var1 = %x\n", global_var1);
    printf("global_var2 = %x\n", global_var2);

    return 0;
}

// test.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

double global_var1;

int fun(void)
{
    printf("in test.c: &global_var1 = %p", &global_var1);
    printf(" global_var1 = %x\n", global_var1);
    printf("sizeof(global_var1) = %d\n", sizeof(global_var1));

    memset(&global_var1, 0, sizeof(global_var1));

    return 0;
}

在gcc中编译得到如下结果：

 

我们可以看到，在main.c和test.c都有一个global_var1，在main.c中的为强符号，在test.c中的为弱符号。因为在test.c中global_var1没有初始化，所以根据规则②得知：编译器选择main.c中的global_var1的值初始化那片内存。不要误认为在test.c中使用global_var1时是用的main.c中的global_var1，我之前错误得这样认为。其实是这样的：main.c中的global_var1和test.c中的global_var1引用的时同一块内存区域，只是在两个文件中代表的意义不同  ---- 在main.c中代表一个int型变量，在test.c中代表一个double型变量，它们的起始地址相同，但占用内存空间是不同的， 在main.c中占用4个字节，在test.c中占用8个字节，这点从上图的两个sizeof输出结果中可以得到验证。

(gdb) break main
Breakpoint 1 at 0x804841d: file main.c, line 14.
(gdb) run
Starting program: /home/astrol/c/elf/dynamic/understand_weak_symbol_by_example/main

Breakpoint 1, main (argc=1, argv=0xbffff6d4) at main.c:14
14              printf("in main.c: &global_var1 = %p", &global_var1);
(gdb) print/x &global_var1
$1 = 0x804a018
(gdb) print/x &global_var2
$2 = 0x804a01c
(gdb) x/8xb &global_var1
0x804a018 <global_var1>:        0x00    0xff    0x00    0xff    0xff    0x00    0xff    0x00
(gdb)

 

        因为在test.c中的global_var1占用八个字节，memset(&global_var1, 0, sizeof(global_var1))将这块内存区域清零，这也就解释了为什么调用fun之后，global_var1和global_var2都变成0的缘故。

  

(gdb) break 27
Breakpoint 1 at 0x80484d2: file main.c, line 27.
(gdb) run
Starting program: /home/astrol/c/elf/dynamic/understand_weak_symbol_by_example/main
in main.c: &global_var1 = 0x804a018 global_var1 = ff00ff00
sizeof(global_var1) = 4
in main.c: &global_var2 = 0x804a01c global_var2 = ff00ff
sizeof(global_var2) = 4
in test.c: &global_var1 = 0x804a018 global_var1 = ff00ff00
sizeof(global_var1) = 8
global_var1 = 0
global_var2 = 0

Breakpoint 1, main (argc=1, argv=0xbffff6d4) at main.c:27
27              return 0;
(gdb) print/x &global_var1
$1 = 0x804a018
(gdb) print/x &global_var2
$2 = 0x804a01c
(gdb) x/8xb &global_var1
0x804a018 <global_var1>:        0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
(gdb)

 

可见在test.c中对global_var1的改动会影响main.c中global_var1和global_var2的值。当程序很大时，这种错误很难发现，所以尽量避免不同类型的符号在多个文件中

 

三、如何避免呢？

1、上策：想办法消除全局变量。全局变量会增加程序的耦合性，对他要控制使用。如果能用其他的方法代替最好。

2、中策：实在没有办法，那就把全局变量定义为static，它是没有强弱之分的。而且不会和其他的全局符号产生冲突。至于其他文件可能对他的访问，可以封装成函数。把一个模块的数据封装起来是一个好的实践。

3、下策：把所有的符号全部都变成强符号。所有的全局变量都初始化，记住，是所有的，哪怕初始值是0都行。如果一个没有初始化，就可能会和其他人产生冲突，尽管别人初始化了。（自己写代码测试一下）。

4、必备之策：GCC提供了一个选项，可以检查这类错误：-fno-common。

 

参考链接：

 http://blog.csdn.net/chgaowei/article/details/7173436 （新手小心：c语言的强符号和弱符号）

http://www.embedded-bits.co.uk/2008/gcc-weak-symbols/ （GCC Weak Symbols）

http://write.blog.csdn.net/postedit/8008629 （ 什么是weak symbol?）

http://winfred-lu.blogspot.com/2009/11/understand-weak-symbols-by-examples.html （Understand Weak Symbols by Examples）

http://discusstolearn.blogspot.sg/2012/11/symbol-resolution-weak-symbols-how.html （Symbol Resolution, Weak Symbols, How compiler resolves multiple Global Symbols）

http://wanderingcoder.net/2012/06/30/multiply-defined-symbols/  （ Dealing with multiply defined symbols）

http://www.cnblogs.com/whos/archive/2010/10/20/1856274.html（弱符号与强符号概念）

http://www.searchtb.com/2013/03/compile_problems_about_strong_weak_symbols.html （分享两个强符号，弱符号引起的编译问题）

http://blog.csdn.net/glp_hit/article/details/8788963 （强符号 弱符号）

 

 补充：

最近在看《程序员的自我修养》，知道现在的编译器和链接器支持一种叫COMMOM块（Common Block）的机制，这种机制用来解决 一个弱符号定义在多个目标文件中，而它们的类型又不同（即大小不同） 的情况。

在目标文件中，编译器将未初始化的全局变量放在了COMMON段，未初始化的静态变量（包括全局和局部静态变量）放在BSS段。

---------------------------------------------------------------------------------------------------------------------------------------

对于全局变量来说，如果初始化了不为0的值，那么该全局变量存储在.data段；

如果初始化的值为0， 那么将其存储在.BSS；（依然是强符号）

如果没有初始化，那么编译时将其存储在COMMON块，等到链接时再将其放入到.BSS段。（这点不同的编译器会有所不同，有的编译器会直接把没有初始化的全局变量放在.BSS段，而没有COMMON块机制）

---------------------------------------------------------------------------------------------------------------------------------------

 

为什么这样处理呢？

 

我们可以想到，当编译器将一个编译单元编译成目标文件的时候，如果该编译单元包含了弱符号（未初始化的全局变量就是典型的弱符号），那么该弱符号最终所占空间的大小此时是未知的，因为有可能其他编译单元中同符号名称的弱符号所占的空间比本编译单元该符号所占的空间要大。所以编译器此时无法为该弱符号在BSS段分配空间，因为所需要的空间大小此时是未知的。但是链接器在链接过程中可以确定弱符号的大小，因为当链接器读取所有输入目标文件后，任何一个弱符号的最终大小都可以确定了，所以它可以在最终的输出文件的BSS段为其分配空间。所以总体来看，未初始化的全局变量还是被放在BSS段。       ------摘自《程序员的自我修养》

来看一个例子：

/* aa.c  */
#include <stdio.h>
int global ;    /* weak symbol */
int main(int argc, const char *argv[])
{
        printf("global = %d, sizeof(global) in main = %d\n", global, sizeof(global));
        bb();
        return 0;
}

 

/* bb.c  */
#include <stdio.h>
double global ; /* weak symbol */
void bb()
{
        printf("global = %f, sizeof(global) in bb = %d\n", global, sizeof(global));
}

 编译成目标文件：

gcc -c aa.c bb.c

得到aa.o 和 bb.o两个目标文件

 

来看看他们的符号表

 

 

可以清楚的看到，在两个目标文件中，Ndx数值都是COM，表示此时它们被放在COMMON块。在aa.o中global的大小是4个字节，在bb.o中global的大小是8个字节。

那么这两个目标文件链接生成可执行文件后，global的大小是多少呢？ -- 当不同的目标文件需要的COMMON块空间大小不一致时，以最大的那块为准。

gcc aa.o bb.o -o cc

得到可执行文件cc

果然，global最终的大小为8个字节。

 所以总体来看，未初始化全局变量最终还是被放在BSS段的。

如果我们给aa.c中的global赋值把它变成强符号呢？如下：

/* aa.c  */
#include <stdio.h>
int global = 100;       /* strong symbol */
int main(int argc, const char *argv[])
{
        printf("global = %d, sizeof(global) in main = %d\n", global, sizeof(global));
        bb();
        return 0;
}

/* bb.c  */
#include <stdio.h>
double global;  /* weak symbol */
void bb()
{
        printf("global = %f, sizeof(global) in bb = %d\n", global, sizeof(global));
}

得到两个目标文件后查看符号，aa.o中global放在.data段，bb.o依然放在COMMON块，最终的cc中global大小4字节，这很好的验证了本文一开始的第二条规则。

 可是有例外情况，看下面程序：

/* aa.c  */
#include <stdio.h>
int global;     /* weak symbol */
int main(int argc, const char *argv[])
{
        printf("global = %d, sizeof(global) in main = %d\n", global, sizeof(global));
        bb();
        return 0;
}

/* bb.c  */
#include <stdio.h>
double __attribute__ ((weak)) global = 1.0;     /* weak symbol */
void bb()
{
        printf("global = %f, sizeof(global) in bb = %d\n", global, sizeof(global));
}

aa.c和bb.c中global都是弱符号，如果按照上面的规则的话，最终的可执行文件中global的大小应该是8个字节，可惜结果并不是我们所期望的：

看到没，最终的可执行文件cc中global所占内存却是4个字节！为什么？ 下面是我在ELF文档里找到的一段：

---------------------------------------------------------------------------------------------------------------------------------------

Global and weak symbols differ in two major ways.
(全局符号和弱符号的区别主要在两个方面。)
When the link editor combines several relocatable object files, it does not allow multiple definitions of STB_GLOBAL symbols with the same name. On the other hand, if a defined global symbol exists, the appearance of a weak symbol with the same name will not cause an error. The link editor honors the global definition and ignores the weak ones. Similarly, if a common symbol exists (i.e., a symbol whose st_shndx field holds SHN_COMMON), the appearance of a weak symbol with the same name will not cause an error. The link editor honors the common definition and ignores the weak ones.
(* 当链接器链接几个可重定位的目标文件时，它不允许具有STB_GLOBAL属性的符号以相同名字进行重复定义。另一方面，如果一个已定义的全局符号存在，则即便另一个具有相同名字的弱符号存在也不会引起错误。链接器将认可全局符号的定义而忽略弱符号的定义。与此相似，如果一个符号被放在COMMON块（就是说这个符号的 st_shndx 成员的值为SHN_COMMON),则一个同名的弱符号也不会引起错误。链接器同样认可放在COMMON块符号的定义而忽略其他的弱符号。)

---------------------------------------------------------------------------------------------------------------------------------------

至于为什么这样处理，目前我还不得而知，如果读者知道的话，麻烦告诉我一下^_^！

再来看一种情况！如下：

/* aa.c  */
#include <stdio.h>
int __attribute__((weak)) global = 1;   /* weak symbol */
int main(int argc, const char *argv[])
{
        printf("global = %d, sizeof(global) in main = %d\n", global, sizeof(global));
        bb();
        return 0;
}

/* bb.c  */
#include <stdio.h>
double __attribute__((weak)) global = 1.0;      /* weak symbol */
void bb()
{
        printf("global = %f, sizeof(global) in bb = %d\n", global, sizeof(global));
}

结果却是：

 看到没，同样都是弱符号，却因为编译顺序的不同，可执行文件中的大小也不同，为什么会这样，目前我也是不得而知！

 

简而言之，在目标文件中没有将未初始化的全局变量像未初始化的静态变量那样放在BSS段，而是放在COMMON块，是因为现在的编译器和链接器允许不同类型的弱符号存在，最本质的原因是链接器无法判断各个符号的类型是否一致。

有了COMMON块之后就可以很好的解决这个问题了。

 

补充：

编程中我们可以使用GCC的“-fno-common”把所有的未初始化的全局变量不以COMMON块的形式处理，也可以使用“__attribute__ ((nocommon))”，如下：

int global __attribute__ ((nocommon));  /* strong symbol */

一旦一个未初始化的全局变量不是以COMMON块的形式存在，那么它就相当于一强符号，如果其他目标文件中还有同一个变量的强符号定义，链接时就会发生符号重复定义错误。

参考链接：

http://blog.chinaunix.net/uid-23629988-id-2888209.html（通过未初始化全局变量，研究BSS段和COMMON段的不同）

http://blog.copton.net/articles/linker/index.html （ C++ and the linker）

http://www.lurklurk.org/linkers/linkers.html （ Beginner's Guide to Linkers）

https://thunked.org/programming/code-obfuscation-with-linker-symbol-abuse-t100.html