User Process Memory Mapping - Is a bss section always the same size?

Question

This may be an older request, but so far I have not found a satisfactory answer. To check the file’s memory card, I wrote a small welcome program.

#include <stdio.h> #include <stdlib.h> int main(void) { printf("Hello\n"); return 0; } 

Now after compilation, when I use the size command in my object file, I get:

 # size hello text data bss dec hex filename 1133 492 16 1641 669 hello 

I also checked the size for other files. I always get bss as 16. Is bss fixed? Whether it is included in the data, or it is from it. I mean that this 16 is included in 492 or not. As I understand it, bss is an uninitialized data segment.

Answer 1

The size of the BSS partition is software dependent. It describes the amount of data that is initialized to "all bytes zero". Zero values ​​are not actually stored in the object file, but the size of the BSS section is preserved.

The data section contains the initial values ​​of all data structures that are not initialized with "all bytes of zero"; It also changes between programs. It does not include the space included in the BSS section.

---

You will get a larger BSS section with this program:

 #include <stdio.h> #include <stdlib.h> #include <time.h> enum { A_SIZE = 100 }; static int a[A_SIZE]; int main(void) { srand(time(0)); for (int i = 0; i < A_SIZE; i++) a[i] = i; for (int i = A_SIZE; i > 0; i--) { int j = rand() % i; // Not good random number generation! int t = a[j]; a[j] = a[i-1]; a[i-1] = t; } for (int i = 0; i < A_SIZE; i++) printf("%d\n", a[i]); return 0; } 

The code shuffles numbers from 0 to 99 with some bias in generating random numbers (so this is not an ideal shuffle, but it really is not an exercise point - it is just non-trivial code that uses a static array, although a local variable will suffice). When I run size (on Ubuntu 13.10), I get:

 text data bss dec hex filename 1593 584 432 2609 a31 shuffle 

For comparison, in the "hello" program in the question, I get:

 text data bss dec hex filename 1200 560 8 1768 6e8 hello 

The main difference is that array a occupies 400 bytes; the remaining 24 bytes of BSS belong to a different code.

Answer 2

A good wikipedia article describes .bss. This is a segment containing statically distributed variables. Thus, the size is included in the size of the object file and is not fixed.

Answer 3

Your request related to .bss has already been answered; but if you look at a memory mapping, which seems to make sense according to your request, I can suggest using utilities like readelf , objdump and nm instead of larger size for more detailed diagnostics. You can also examine map files for gcc , which can be generated using the -Wl,-M linker options on the console (stdout) or using -Wl,-Map,<map_file_name> , which provide display of characters using ld and global storage .
PS: Very well-answered request related to .bss on SO: Do.bss section zero initialized variables occupy space in elf file?

Answer 4

BSS would be bigger if you had, for example, an uninitialized array: For example. char bss[100];

Essentially, every static variable that is not initialized goes to BSS.