Why 'int x = 0' is uninitialized data to the GNU C compiler
This article is about a curiosity of gcc that will
interest almost nobody.
I came across it whilst implementing a program loader that could
load binary code into RAM on a Raspberry Pi Pico. I suspect that this is the only application where the initialization
behaviour of the C compiler is of any significance whatsoever,
Still, I thought it worth writing up because, apart from anything else, it's
such bizarre behaviour that I can imagine myself being caught by it
again later, when my own intracranial RAM needs to be refreshed.
I noticed the problem when different (global) variables in my programs, although of the same type, were being treated differently at runtime. For example, I had variables defined like this:
int max_columns=80; int starting_column=0;
I couldn't work out why max_columns seemed to take the
correct value, 80, but starting_colums had a crazy
value.
Now, I'm writing the program loader myself so, of course, I could well understand why all the global variables would end up with crazy values. It would just be a bug in my loader. I could even understand why variables of a particular type or storage class might have ended up with crazy values. However, after much experimentation I realized that the crazy values were all assigned to variables which were initialized to zero in my code. It turned out I could set any value except zero.
Let's look at a simple example to see why this happens. Although I'm
working on an embedded device, the problem can be seen quite easily using
the ordinary Linux gcc.
Compile and link this trivial program:
int aa1 = 42;
int aa2 = 6;
int aa3 = 0;
int aa4;
int main() { return 0; }
$ gcc -o test test.c
I've chosen these "aa" names just to make it easy to find the variables
in the ELF file created by gcc:
$ objdump --all test | grep aa
The output, on my system, is:
000000000040401c g O .data 0000000000000004 aa1 0000000000404020 g O .data 0000000000000004 aa2 0000000000404028 g O .bss 0000000000000004 aa3 000000000040402c g O .bss 0000000000000004 aa4
Notice that aa1 and aa2 -- variables that
are assigned non-zero values in my program -- are in .data
segments. But aa3, which is assigned the value 0, and
aa4, which is not assigned a value at all, are in
.bss segments.
The problem was that my program loader was not initializing the BSS segments
correctly. So variables whose values were stored in those segments were
not getting zeroed. Since aa3 specifically had to be
zero, not zeroing it was a significant error.
But why are different variables of the same type in different segments?
What's so special about the value zero?
The fact is that I don't really know. I presume that this is some kind
of optimization carried out by gcc, in an attempt to be
save a few bytes somewhere.
Conventionally, 'data' segments are used to store values that have been initialized specifically by the programmer. It matters what the values are, and they are stored in the executable file generated by the compiler.
'BSS' segments, however, are traditionally used to "store" variables that have not explicitly been given an initial value. "Store" isn't really the right word here: the linker does not have to allocate any space in the executable file for values of these variables -- they are just placeholders.
Although no values are stored in the executable,
values still have to be set in memory.
The C language standards,
however, stipulate that uninitialized global variables take the
value zero at runtime. So somebody has to initialize them.
Setting these values to zero is not the responsibility of
the compiler -- at least, it is not in the GCC world. Instead, some
start-up code, executed before main() is invoked, has
to zero all this data.
I can only imagine that gcc assumes that, if the programmer
sets a global variable to zero, it doesn't actually need
to store the zero value in the executable. If it assigns it to a
BSS segment, the start-up code will zero it along with all the other
BSS data. And, frankly, neither the program nor the programmer usually
care about the exact addresses in memory where data is stored. So this
slightly odd behaviour potentially results in a modest saving
of executable size, at least if large numbers of variables
are involved.
It isn't an accident that gcc behaves this way. It turns out
that, on some platforms, gcc has a specific switch to
control this behaviour: -fzero-initialized-in-bss.
As I said, this is an oddity that will affect almost nobody. The default behaviour seems, well, wrong to me; but, unless you're implementing a program loader, you probably won't even notice.
