简体   繁体   中英

Why do .o files appear to have a .bss section of size 0 when compiled with GCC?

While working on a C program, I altered my build to produce ao file instead of a stand-alone binary. When doing so, I noticed that the size of the.bss section of the resulting.o file is 0, according to readelf -S even though there are clearly uninitialized globals in the source.

I can replicate this with a simple program, test.c:

char arr[42];
int main(int argc, char **argv){
  return 0;
}

The binary resulting from gcc -o test test.c has an eighty byte.bss section, according to readelf, which is roughly what I'd expect, as I expected some minor overhead.

However, if I build ao file with gcc -c -o test.o test.c , the size of the bss section is reported as zero. Clearly I'm misunderstanding something about the nature of ELF object files, but I'm not quite sure what I'm missing.

ELF object files have a dummy.bss segment. They can not be loaded directly (unlike an executable or shared library).

The information about the global variables is stored in the.symtab section, which is used by the linker to construct the.bss and other sections in the final binary.

Try doing readelf -s test.o to reveal the symbol table.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM