understanding size command for data bss segment in C - c

Question

I'm getting unexpected output from size command.
Afaik initialized global and static variables stored in data segment and uninitialized and initialized to 0 global/static variables stored in bss segment.
printf("%d",sizeof(int)); gives int size 4. However, bss and data segment is not increasing accordingly to 4.
#include <stdio.h>
int main()
{
return 0;
}
C:\Program Files (x86)\Dev-Cpp\MinGW64\bin>size memory-layout.exe
text data bss dec hex filename
10044 2292 2512 14848 3a00 memory-layout.exe
#include <stdio.h>
int g; //uninitialised global variable so, stored in bss segment
int main()
{
return 0;
}
C:\Program Files (x86)\Dev-Cpp\MinGW64\bin>size memory-layout.exe
text data bss dec hex filename
10044 2292 2528 14864 3a10 memory-layout.exe
why bss increased by 16 (2528 - 2512) instead of 4? (in above code)
#include <stdio.h>
int g=0; //initialised to 0 so, stored in bss segment
int main()
{
return 0;
}
C:\Program Files (x86)\Dev-Cpp\MinGW64\bin>size memory-layout.exe
text data bss dec hex filename
10044 2292 2512 14848 3a00 memory-layout.exe
there is no increment in bss in spite of using global variable. why's that?
#include <stdio.h>
int main()
{ static int g; //should be on bss segment
return 0;
}
C:\Program Files (x86)\Dev-Cpp\MinGW64\bin>size memory-layout.ex
text data bss dec hex filename
10044 2292 2512 14848 3a00 memory-layout.exe
no increment in bss segment in spite of using static variable, why?
and I have one more question, what dec represents here?

Answer 1

The first thing to consider is memory alignment. Variables and sections can be padded to make them sit on address boundaries. In the second example you are seeing an increase of 16 from the first, which suggests padding for 16-byte boundaries (2512 / 16 = 157, 2528 / 16 = 158). This is entirely implementation dependent.
As far as C is concerned, the second example differs from the third because the compiler cannot know if int g is a definition or just a declaration for an integer defined in another file (where it could be any value). It leaves a reference for the linker to deal with instead, which may lead to differences in padding.
In the third example, g is explicitly defined and set to 0, so the compiler knows to put this in the BSS section.
It's possible to demonstrate this with the generated assembly from my system:
with int g (no BSS section is defined in this case)
.comm g,4,4
This is a instruction for the linker to deal with the symbol, as the compiler cannot fully determine what to do with it.
with int g = 0
.bss
.align 4
.type g, #object
.size g, 4
g:
.zero 4
Here the compiler knows exactly what to do and so defines a BSS section for the symbol.
In my case, the linker resolves these identically. Both are placed in the BSS section at the same address, and so there is no difference in BSS size. You can examine the layout with a utility like nm.
nm -n file2 file3 | grep g$
000000000060103c B g
000000000060103c B g
i.e. on this system g is at the same address. Alternatively, with a debugger:
(gdb) info symbol 0x60103c
g in section .bss of /tmp/file2
Note also that in the final example the variable can be optimised out, since it has internal linkage.
As for dec, it is simply the sum of the sections in decimal.

Answer 2

This is from gcc on linux:
No Variable
text data bss dec hex filename
915 248 8 1171 493 none.out
Uninitialized Global
text data bss dec hex filename
915 248 12 1175 497 u_g.out
Initialized Global to 123
text data bss dec hex filename
915 252 8 1175 497 i_g.out
Initialized Local to 124
text data bss dec hex filename
915 252 8 1175 497 i_l.out
Initialized Global to 0
text data bss dec hex filename
915 248 12 1175 497 i_g_0.out
Initialized Local to 0
text data bss dec hex filename
915 248 12 1175 497 i_l_0.out
This is from mingw64 on Windows:
No Variable
text data bss dec hex filename
3173 1976 448 5597 15dd none.out
Uninitialized Global
text data bss dec hex filename
3173 1976 464 5613 15ed u_g.out
Initialized Global to 123
text data bss dec hex filename
3173 1976 448 5597 15dd i_g.out
Initialized Local to 124
text data bss dec hex filename
3173 1976 448 5597 15dd i_l.out
Initialized Global to 0
text data bss dec hex filename
3173 1976 480 5629 15fd i_g_0.out
Initialized Local to 0
text data bss dec hex filename
3173 1976 480 5629 15fd i_l_0.out
So although I don't have a final answer to the question (wouldn't fit in a comment), results make me suspect the executable file format of Windows and/or MinGW (i.e. not gcc).

Answer 3

BSS only contains static and global values which are not explicitly initialized. Even though you are explicitly initializing it to the same value to which it would be initialized if it were not initialized explicitly, the fact of explicit initialization means it doesn't belong in bss.