This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Where are static variables stored (in C/C++)?
I've read that all global variables that are initialized will be allocated space on the initialized data segment and all static and global variables that are not initialized are initialized to 0, and allocated on the BSS. In case of the following definition,
static int i = 0;
where will space for i be allocated? Will it be on the initialized data segment because i is initialized, or will it be on the BSS since the value of i is 0?
Yes, non-initialized static variables will be initialized to 0 by default, that's always true in C.
The storage location of the data will be implementation dependent... I've seen that it's the 0 initialized static variables (i in your case) that goes in .BSS (Block Started by Symbol).
Non-0 initialized statics go into .DATA static int i=2; for example.
To show the point:
int main(int argc, char * argv[])
{
return 0;
}
saved in "test.c"
> gcc test.c
> size a.out
text data bss dec hex filename
1056 252 8 1316 524 a.out
Then we update it as such:
int main(int argc, char * argv[])
{
static int i;
return 0;
}
> gcc test.c
> size a.out
text data bss dec hex filename
1056 252 12 1316 524 a.out
Change it again as such:
int main(int argc, char * argv[])
{
static int i = 2;
return 0;
}
> gcc test.c
> size a.out
text data bss dec hex filename
1056 256 8 1316 524 a.out
This really depends on the actual compiler/implementation, but yes, i would most likely be on the BSS because it's either on file level (i.e. outside any function) or static and inside a function and has a value of 0.
It's implementation dependant, on Linux with gcc 4.5.2 when I compile this program:
static int a[1000000] = {1}; void main() {}
I get executable with size 3.9M - first element of the array is initialized (with non-zero value) so array 'a' goes to .data segment.
When I initialize array with zeros:
static int a[1000000] = {0}; void main() {}
I get executable with size 8.2K - I guess that such difference in size indicates that this time 'a' array was located in .bss segment.
Related
Consider the following 3 programs:
static1.c
int main(int argc, char * argv[])
{
return 0;
}
static2.c
int main(int argc, char * argv[])
{
static int i;
return 0;
}
static3.c
int main(int argc, char * argv[])
{
static int i = 2;
return 0;
}
Now the size for each program is invoked:
size static1.out
text data bss dec hex filename
1418 544 8 1970 7b2 static1.out
size static2.out
text data bss dec hex filename
1418 544 8 1970 7b2 static2.out
size static3.out
text data bss dec hex filename
1418 548 4 1970 7b2 static3.out
Why is the size output same for static1.c and static2.c, even if there is an uninitialised/zero initialised static variable in static2.out, which must go to .bss segment?
In all 3 programs the variable is never used. If the compiler is smart enough to deduce that, then why did the size information in static3.c different from other two?
If the .data and .bss are 544 and 8 respectively(without any variables), then only .data segment should change in the static3.c but from the output we can see that the int moved from .bss to .data(because the variable has an initial value now)
I wrote the simple C program (test.c) below:-
#include<stdio.h>
int main()
{
return 0;
}
and executed the follwing to understand size changes in .bss segment.
gcc test.c -o test
size test
The output came out as:-
text data bss dec hex filename
1115 552 8 1675 68b test
I didn't declare anything globally or of static scope. So please explain why the bss segment size is of 8 bytes.
I made the following change:-
#include<stdio.h>
int x; //declared global variable
int main()
{
return 0;
}
But to my surprise, the output was same as previous:-
text data bss dec hex filename
1115 552 8 1675 68b test
Please explain.
I then initialized the global:-
#include<stdio.h>
int x=67; //initialized global variable
int main()
{
return 0;
}
The data segment size increased as expected, but I didn't expect the size of bss segment to reduce to 4 (on the contrary to 8 when nothing was declared). Please explain.
text data bss dec hex filename
1115 556 4 1675 68b test
I also tried the comands objdump, and nm, but they too showed variable x occupying .bss (in 2nd case). However, no change in bss size is shown upon size command.
I followed the procedure according to:
http://codingfox.com/10-7-memory-segments-code-data-bss/
where the outputs are coming perfectly as expected.
When you compile a simple main program you are also linking startup code.
This code is responsible, among other things, to init bss.
That code is the code that "uses" 8 bytes you are seeing in .bss section.
You can strip that code using -nostartfiles gcc option:
-nostartfiles
Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used
To make a test use the following code
#include<stdio.h>
int _start()
{
return 0;
}
and compile it with
gcc -nostartfiles test.c
Youll see .bss set to 0
text data bss dec hex filename
206 224 0 430 1ae test
Your first two snippets are identical since you aren't using the variable x.
Try this
#include<stdio.h>
volatile int x;
int main()
{
x = 1;
return 0;
}
and you should see a change in .bss size.
Please note that those 4/8 bytes are something inside the start-up code. What it is and why it varies in size isn't possible to tell without digging into all the details of mentioned start-up code.
In a 64-bit machine, I write a simple C program as follows:
#include <stdio.h>
int main(int argc,char* argv[])
{
printf("Hello,world!\n");
return 0;
}
Then gcc hello.c -o hello, size hello, I got:
text data bss dec hex filename
1156 492 16 1664 680 hello
Next, I add a global int variable in the source code:
#include <stdio.h>
int global;
int main(int argc,char* argv[])
{
printf("Hello,world!\n");
return 0;
}
Again compile and size, I got:
text data bss dec hex filename
1156 492 24 1672 688 hello
So, the question is, bss segment has got an increment of 8 bytes, but why? There is only an int variable global added. That should be 4.
BTW, gcc version is 4.4.7
The segment size is rounded up to the next multiple of 8, so that anything that follows it will be aligned on a 64 bit boundary. The startup routine that zeroes it will use 64 bit stores anyway.
I write a basic code as
#include<stdio.h>
int main(void)
{
return 0;
}
and check its size as
gcc -Wall test1.c
size a.out
text data bss dec hex filename
988 260 8 1256 4e8 a.out
Just for knowledge i want to know that i do not declare any variable global or local, initialize or uninitialized then why data and bss is shown as 260 and 8 respectively.
Is this for stack pointer and other variables required for code execution ?
here is a simple code that I executed
int a;
int main()
{
return 0;
}
Then after compiling with gcc I did
size a.out
I got some output in bss and data section...Then I changed my code to this
int a;
int main()
{
char *p = "hello";
return 0;
}
Again when I saw the output by size a.out after compiling , size of data section remained same..But we know that string hello will be allocated memory in read only initialized part..Then why size of data section remained same?
#include <stdio.h>
int main()
{
return 0;
}
It gives
text data bss dec hex filename
960 248 8 1216 4c0 a.out
when you do
int a;
int main()
{
char *p = "hello";
return 0;
}
it gives
text data bss dec hex filename
982 248 8 1238 4d6 a.out
at that time hello is stored in .rodata and the location of that address is stored in char pointer p but here p is stored on stack
and size doesnt shows stack. And i am not sure but .rodata is here calculated in text or dec.
when you write
int a;
char *p = "hello";
int main()
{
return 0;
}
it gives
text data bss dec hex filename
966 252 8 1226 4ca a.out
now here again "hello" is stored in .rodata but char pointer takes 4 byte and stored in data so data is increment by 4
For more info http://codingfreak.blogspot.in/2012/03/memory-layout-of-c-program-part-2.html
Actually, that's an implementation detail. The compiler works by an as-is principle. Meaning that as long as the behavior of the program is the same, it's free to exclude any piece of code it wants. In this case, it can skip char* p = "hello" altogether.
The string "hello" is allocated in the section .rodata
Even if the total size doesn't changed, it doesn't mean that the code didn't.
I tested your example.
The string "hello" is a constant data, thus it is stored in the readonly .rodata section.
You can see this particular section using objdump, for example:
objdump -s -j .rodata <yourbinary>
With gcc 4.6.1 without any options, I got for your second code:
Contents of section .rodata:
4005b8 01000200 68656c6c 6f00 ....hello.
Since you don't use that char * in your code, the compiler optimized it away.