Relationship between .bss section size and object/executable file size - c++

Question

If I have a C or CPP program written like
#include <stdio.h>
int bss_section_object[10];
int main()
{
return 0;
}
After compiling the code with gcc/g++,
$g++ -save-temps aa.cpp
If I check the size of generated object and executable files
$ls -ltr
-rw-rw-r-- 1 dinesh dinesh 77 Feb 14 12:42 aa.cpp
-rw-rw-r-- 1 dinesh dinesh 17283 Feb 14 12:45 aa.ii
-rw-rw-r-- 1 dinesh dinesh 517 Feb 14 12:45 aa.s
-rw-rw-r-- 1 dinesh dinesh 1296 Feb 14 12:45 aa.o
-rwxrwxr-x 1 dinesh dinesh 8592 Feb 14 12:45 a.out
$size a.out
text data bss dec hex filename
1099 544 72 1715 6b3 a.out
$size aa.o
text data bss dec hex filename
67 0 40 107 6b aa.o
Now if I comment the object created on .bss section
#include <stdio.h>
//int bss_section_object[10];
int main()
{
return 0;
}
and check the size after compling it:-
$ls -ltr
-rw-rw-r-- 1 dinesh dinesh 79 Feb 14 12:46 aa.cpp
-rw-rw-r-- 1 dinesh dinesh 17256 Feb 14 12:46 aa.ii
-rw-rw-r-- 1 dinesh dinesh 378 Feb 14 12:46 aa.s
-rw-rw-r-- 1 dinesh dinesh 1232 Feb 14 12:46 aa.o
-rwxrwxr-x 1 dinesh dinesh 8552 Feb 14 12:46 a.out
$size a.out
text data bss dec hex filename
1099 544 8 1651 673 a.out
$size aa.o
text data bss dec hex filename
67 0 0 67 43 aa.o
I can see that their size varies based on "bss_section_object" size.
If I read the details of .bss section, then as per wikipedia:-
"The size that BSS will require at runtime is recorded in the object file,
but BSS (unlike the data segment) doesn't take up any actual space in the
object file".
We can see similar description of .bss section in other computer science
books as well.
Now, If the .bss section doesn't take up any space in object file, then why
is the size of object as well as executable file changing based on size of
object created on .bss section?
Can someone please explain the details about it?

Answer 1

You are perfectly right when saying :
"The size that BSS will require at runtime is recorded in the object file, but BSS (unlike the data segment) doesn't take up any actual space in the object file"
Because uninitialized data is placed in the .bss section of the program, which is of type SHT_NOBITS (see the elf(5) manpage).
To convince yourself that this section doesn't takes up any space in the ELF file, try readelf -Wl /bin/ls and look at the fourth segment :
[...]
LOAD 0x01a310 0x000000000061a310 0x000000000061a310 0x0012f0 0x002010 RW 0x200000
[...]
`03 .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss
You can see that it contains (among others), the .bss section, and has file size 0x12f0 but memory size 0x2010. The difference is the size of the .bss section.
This section is not included in the file because the associated memory region will be zeroed out at program startup, and it would be unnecessary to store zeros in the file.
You're right, but your test is wrong
In the example you give, given that you disable optimization and debugger symbols, the difference you see in file size may be explained by the symbol table, and not by the change of the .bss section size.
Here's an experiment you can reproduce :
you$ cat main.cpp
#include <stdio.h>
#ifdef USE_BSS
int bss_section_object[10];
#endif
int main()
{
return 0;
}
you$ g++ -O0 main.cpp -o without.elf
you$ g++ -DUSE_BSS -O0 main.cpp -o with.elf
you$ ls -l *.elf
-rwxr-xr-x. 1 you you 8505 Feb 14 10:00 with.elf
-rwxr-xr-x. 1 you you 8462 Feb 14 10:00 without.elf
At this point, you may believe that changing the .bss section size affects the file size, but in fact the difference is due to the additional symbol bss_section_object in the symbol table (which you can remove using the strip command) :
you$ readelf -WS with.elf > with && readelf -WS without.elf > without
you$ diff with without
30c30
< [25] .bss NOBITS 0000000000601040 00102c 000048 00 WA 0 0 32
---
> [25] .bss NOBITS 000000000060102c 00102c 000004 00 WA 0 0 4
33,34c33,34
< [28] .symtab SYMTAB 0000000000000000 0018e8 000618 18 29 45 8
< [29] .strtab STRTAB 0000000000000000 001f00 000239 00 0 0 1
---
> [28] .symtab SYMTAB 0000000000000000 0018e8 000600 18 29 45 8
> [29] .strtab STRTAB 0000000000000000 001ee8 000226 00 0 0 1
# Yep, the .symtab and .strtab are also different
you$ strip *.elf
you$ ls -l *.elf
-rwxr-xr-x. 1 you you 6232 Feb 14 10:06 with.elf
-rwxr-xr-x. 1 you you 6232 Feb 14 10:06 without.elf
Yay ! By removing the symbol table section .symtab (it its associated string table .strtab), you end up with the same file size, but different .bss section sizes, which is what you expected.