通过readelf检查目标文件的反汇编时，我看到数据和bss段包含相同的偏移地址。 数据部分将包含初始化的全局变量和静态变量。 BSS将包含非主动化的全局变量和静态变量。
1 #include<stdio.h>
2
3 static void display(int i, int* ptr);
4
5 int main(){
6 int x = 5;
7 int* xptr = &x;
8 printf("\n In main() program! \n");
9 printf("\n x address : 0x%x x value : %d \n",(unsigned int)&x,x);
10 printf("\n xptr points to : 0x%x xptr value : %d \n",(unsigned int)xptr,*xptr);
11 display(x,xptr);
12 return 0;
13 }
14
15 void display(int y,int* yptr){
16 char var[7] = "ABCDEF";
17 printf("\n In display() function \n");
18 printf("\n y value : %d y address : 0x%x \n",y,(unsigned int)&y);
19 printf("\n yptr points to : 0x%x yptr value : %d \n",(unsigned int)yptr,*yptr);
20 }
输出：
SSS:~$ size a.out
text data bss dec hex filename
1311 260 8 1579 62b a.out
在上面的程序中，我没有任何非本地化数据，但BSS占用了8个字节。为什么它占用8个字节？ 当我反汇编目标文件时，
已编辑：
[ 3] .data PROGBITS 00000000 000110 000000 00 WA 0 0 4
[ 4] .bss NOBITS 00000000 000110 000000 00 WA 0 0 4
[ 5] .rodata PROGBITS 00000000 000110 0000cf 00 A 0 0 4
data，rodata和bss具有相同的偏移地址。这是指rodata，data和bss是指同一个地址吗？ Data section，rodata section和bss section是否包含相同地址的数据值，若有，如何区分数据部分，bss部分和rodata部分？
答案 0 :(得分：38)
当程序加载到内存中时，.bss部分保证全为零。因此，任何未初始化或初始化为零的全局数据都会放在.bss部分中。例如：
static int g_myGlobal = 0; // <--- in .bss section
关于这一点的好处是，.bss部分数据不必包含在磁盘上的ELF文件中（即，文件中没有整个零区域） .bss部分）。相反，加载器从节标题中知道要为.bss部分分配多少，并在将控制权移交给您的程序之前简单地将其清零。
注意readelf输出：
[ 3] .data PROGBITS 00000000 000110 000000 00 WA 0 0 4
[ 4] .bss NOBITS 00000000 000110 000000 00 WA 0 0 4
.data被标记为PROGBITS。这意味着有＆＃34;比特＆＃34;加载程序需要为您读入内存的ELF文件中的程序数据。另一方面，.bss标记为NOBITS，这意味着文件中没有任何内容需要作为加载的一部分读入内存。
示例：
// bss.c
static int g_myGlobal = 0;
int main(int argc, char** argv)
{
return 0;
}
使用$ gcc -m32 -Xlinker -Map=bss.map -o bss bss.c
使用$ readelf -S bss
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
:
[13] .text PROGBITS 080482d0 0002d0 000174 00 AX 0 0 16
:
[24] .data PROGBITS 0804964c 00064c 000004 00 WA 0 0 4
[25] .bss NOBITS 08049650 000650 000008 00 WA 0 0 4
:
现在我们在符号表中查找变量：$ readelf -s bss | grep g_myGlobal
37: 08049654 4 OBJECT LOCAL DEFAULT 25 g_myGlobal
请注意，g_myGlobal显示为第25部分的一部分。如果我们回顾部分标题，我们会看到25是.bss。
回答您的真实问题：
在上面的程序中，我没有任何非本地化数据，但BSS占用了8个字节。为什么它占用8个字节？
继续我的例子，我们在第25节中寻找任何符号：
$ readelf -s bss | grep 25
9: 0804825c 0 SECTION LOCAL DEFAULT 9
25: 08049650 0 SECTION LOCAL DEFAULT 25
32: 08049650 1 OBJECT LOCAL DEFAULT 25 completed.5745
37: 08049654 4 OBJECT LOCAL DEFAULT 25 g_myGlobal
第三列是大小。我们看到了预期的4字节g_myGlobal和1字节completed.5745。这可能是来自C运行时初始化中某处的函数静态变量 - 请记住，很多＆＃34; stuff＆＃34;在调用main()之前发生。
4 + 1 = 5个字节。但是，如果我们回顾.bss节标题，我们会看到最后一列Al是4.这是节对齐，这意味着此节在加载时将始终是4字节的倍数。从5开始的下一个多数是8，这就是.bss部分为8个字节的原因。
另外我们可以查看链接器生成的地图文件，看看哪些目标文件放在最终输出的哪个位置。
.bss 0x0000000008049650 0x8
*(.dynbss)
.dynbss 0x0000000000000000 0x0 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib/crt1.o
*(.bss .bss.* .gnu.linkonce.b.*)
.bss 0x0000000008049650 0x0 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib/crt1.o
.bss 0x0000000008049650 0x0 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib/crti.o
.bss 0x0000000008049650 0x1 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/32/crtbegin.o
.bss 0x0000000008049654 0x4 /tmp/ccKF6q1g.o
.bss 0x0000000008049658 0x0 /usr/lib/libc_nonshared.a(elf-init.oS)
.bss 0x0000000008049658 0x0 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/32/crtend.o
.bss 0x0000000008049658 0x0 /usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib/crtn.o
同样，第三列是大小。
我们看到.bss的4个字节来自/tmp/ccKF6q1g.o。在这个简单的例子中，我们知道这是来自bss.c文件编译的临时目标文件。另外1个字节来自crtbegin.o，它是C运行时的一部分。
最后，因为我们知道这个1字节的神秘bss变量来自crtbegin.o，并且它的名字是completed.xxxx，它的真实姓名是completed，它可能是某个功能中的静态。查看crtstuff.c，我们发现了罪魁祸首：static _Bool completed内的__do_global_dtors_aux()。
答案 1 :(得分：2)