understanding size command for data bss segment in C

Question

I\'m getting unexpected output from size command.

Afaik initialized global and static variables stored in data segment and uninitialized

Answer 1

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 2

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.

Answer 3

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.