Re: [arm-gnu] zeroing out the .bss area

[Charles Manning <manningc2@xxxxxxxxxxxxx>]

On Wednesday 04 November 2009 12:50:16 JJ wrote:
> > No. That is entirely correct.
>
> Incorrect?

>
> > A statically allocated variable that is initialised to zero will end up
> > in bss too.
> >
> > int foo=1; // .data
> > int bar=0; // .bss
> > int uninitilised_var; //.bss


> Shouldn't these variables have the "static" prefix? Variables within
> functions that don't have the "static" prefix aren't added to this
> area correct?

No.

static means different things in different places.

Consider

int a;
static int b;

void func(void)
{
	int c;
	static int d;
}

a,b,d all have fixed statically assigned addresses put in .bss or .data they 
will all exist independent of whether or not you execute foo() and keeps its 
value from one execution of foo() to the next.

c is put on the stack (or in a register) and is not assigned a fixed location. 
It will come and go according to the execution of foo() and will not keep its 
value between invocations of func().

a will be accessible from other files.
b will only be accessible to functions in this file.
c is only accessible within func(). 

all a,b,d will end up in .bss if initialised to zero explicitly or implicitly. 
They will end up in .data if initialised to non-zero.

> What about class variables?
>
> class abc {

Same basic rules apply for classes objects and structs (there isn't much 
difference really).

If a struct or object is all zero initialised then it ends up in .bss, 
otherwise in .data (unless of course it is on the stack).

However, there is a twist... objects containing vtable pointers might not be 
completely zero since the vtable pointer is non zero. This is compiler 
dependent... and I'm unsure of how gcc does it.

Why not do some experiments: Build a binary and look at the map file to see 
where different variables turn up.