c - C中data段和bss段的区别

Question

当通过readelf检查目标文件的反汇编时，我看到data和bss段包含相同的偏移地址。data 部分将包含初始化的全局变量和静态变量。 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个字节呢？另外，当我反汇编目标文件时，

EDITED :

  [ 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节、rodata节和bss节是否包含同一地址中的数据值，如果是，如何区分data节、bss节和rodata节？

Answer 1

当程序加载到内存中时，.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。这意味着 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。

<小时/>

回答您真正的问题:

Here in the above program I dont have any un-intialised data but the BSS has occupied 8 bytes. Why does it occupy 8 bytes ?

继续我的示例，我们在第 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 运行时初始化中某处的函数静态变量 - 请记住，在调用 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

同样，第三列是大小。

我们看到 4 个字节的 .bss 来自 /tmp/ccKF6q1g.o。在这个简单的示例中，我们知道这是编译 bss.c 文件时的临时目标文件。另外 1 个字节来自 crtbegin.o，它是 C 运行时的一部分。

<小时/>

最后，由于我们知道这个1字节的神秘bss变量来自crtbegin.o，并且它的名字是completed.xxxx，所以它的真实名称是completed 它可能是某个函数内的静态。正在查看crtstuff.c我们找到了罪魁祸首:__do_global_dtors_aux() 内部的 static _Bool Completed。