text,data and bss

[c.lang.myself]

i just got to know there are three different sections in which we can
divide our program
*Text section
*Data section
*Bss

i think text section contain our code,data section include heap,stack
(?) etc.

Can any body throw light on Bss section...

 

[Joachim Schmitz]

i just got to know there are three different sections in which we can
divide our program
*Text section
*Data section
*Bss

i think text section contain our code,data section include heap,stack
(?) etc.

Can any body throw light on Bss section...

http://en.wikipedia.org/wiki/.bss

Bye, Jojo

 

[Antoninus Twink]

i just got to know there are three different sections in which we can
divide our program
*Text section
*Data section
*Bss

i think text section contain our code,data section include heap,stack
(?) etc.

The heap and stack occupy the virtual memory locations above the text
and data segments. The heap will grow upwards, the stack downwards from
the highest memory address.

Here is a picture:

highest address
=========
| stack |
| vv |
| |
| |
| ^^ |
| heap |
=========
| bss |
=========
| data |
=========
| text |
=========
address 0

Can any body throw light on Bss section...

Variables that are initialized to 0 are placed in the BSS segment.
Static variables not initialized to 0, constants, strings, etc. are
placed in the data segment.

 

[Bartc]

i just got to know there are three different sections in which we can
divide our program
*Text section

Executable code

*Data section

Static data (variables etc) initialised at compile time. Both of these use
up space in the executable.

*Bss

Static data (variables etc) uninitialised at compile time (or possibly,
initialised to zero). These take no data space in the executable. At runtime
you would hope these are initialised to zero.

i think text section contain our code,data section include heap,stack
(?) etc.

Heap and stack are assigned at runtime. They take up no space in the
executable although it may specify what size they should be, especially the
stack.

This is all in the context of a typical C implementation that uses
traditional compilation and linking and the concept of an executable file.
In theory C could be implemented entirely differently. Or even slightly
differently...

 

[Keith Thompson]

i just got to know there are three different sections in which we can
divide our program
*Text section
*Data section
*Bss

i think text section contain our code,data section include heap,stack
(?) etc.

Can any body throw light on Bss section...

This question really has nothing to do with the C language. It's
entirely determined by your operating system, and can vary from one
system to another. The same C program compiled on different systems
might have different sections; a C program and a Fortran program
compiled on the same system will probably have the same sections with
the same meanings. The C language itself says nothing about text,
data, and bss sections.

So your question would be appropriate in a newsgroup that discusses
your operating system, perhaps comp.unix.programmer or
comp.os.ms-windows.programmer.win32. But you can probably answer it
more easily with a quick Google search.

 

[James Harris]

i just got to know there are three different sections in which we can
divide our program
*Text section
*Data section
*Bss

i think text section contain our code,data section include heap,stack
(?) etc.

Can any body throw light on Bss section...

Think of the work of the program loader. To load a program it has to
basically do the following.

1. Allocate memory for the program executable code and load the code
from the executable file into that space.
2. Allocate memory for a stack.
3. Allocate memory for program data - say 300 bytes are needed of
which 200 have initial values and 100 are not initialised. It loads
the first 200 bytes of initial values from the executable file. The
remaining 100 bytes have no initial values so they are not part of the
executable file but there still needs to be space allocated for them
when the program runs. The last 100 bytes is the bss section.

The need for both predefined data and uninitialised data can be seen
in the these two statements. Think of them as global or static.

float a = 53.0;
float b;

Variable a and others like it which have an initial value will be
assigned to the data section. Variable b and others which are not
initialised are assigned to bss. Since values in bss are not specified
the compiled code does not need to specify initial values for them,
they don't need to take up space in the executable file and the
program loader doesn't need to spend time loading them from disk.

 

[James Harris]

http://en.wikipedia.org/wiki/.bss

Is the current Wikipedia entry right? It says that bss contains
initially zero-filled values. Surely the bss holds _undefined_ data.
Maybe some operating systems zero-fill the space but that is OS-
dependent. Also, all-zero bit patterns do not necessarily signify
zeroes in all data types. For example, floating point zeroes are not
necessarily all-zeroes patterns.

Comments?

 

[Stephen Sprunk]

Is the current Wikipedia entry right? It says that bss contains
initially zero-filled values. Surely the bss holds _undefined_ data.
Maybe some operating systems zero-fill the space but that is OS-
dependent.

The .bss section is officially "uninitialized", but AFAIK all modern
OSes either create new user-space pages as zero-filled (for security
reasons) or require that the C compiler insert start-up code to
zero-fill the uninitialized space (e.g. with memset()). All global and
static C variables go there if they have an initial value of zero, so
someone must be responsible for making that true. If such a variable
had any other initial value, it would go in .data and be copied directly
from the object file to memory.

The entire purposes of .bss was to get zero-initialized variables out of
..data. In a sense, it's a compression scheme.

Also, all-zero bit patterns do not necessarily signify
zeroes in all data types. For example, floating point zeroes are not
necessarily all-zeroes patterns.

If that condition did not hold, the compiler would not be allowed to put
floating point variables in .bss. In practice, the all-zeros bit
pattern is often defined to mean zero for this and related reasons.

S

 

[Keith Thompson]

Is the current Wikipedia entry right? It says that bss contains
initially zero-filled values. Surely the bss holds _undefined_ data.
Maybe some operating systems zero-fill the space but that is OS-
dependent. Also, all-zero bit patterns do not necessarily signify
zeroes in all data types. For example, floating point zeroes are not
necessarily all-zeroes patterns.

Comments?

I don't know about the first part, but since bss is entirely
system-specific (even though it's used on multiple systems), it's
entirely possible that all systems that use bss have null pointers and
floating-point zeros represented as all-bits-zero.

Alternatively, a C implementation on a system where null pointers
and/or floating-point zeros have some other representation would have
to be careful about how it uses bss.

Which emphasizes the point that this is not a question about the C
language.

 

[Lew Pitcher]

On November 16, 2008 11:56, in comp.lang.c, Stephen Sprunk
([email protected]) wrote:
[snip]

The entire purposes of .bss was to get zero-initialized variables out of
.data. In a sense, it's a compression scheme.

IIRC, the entire purpose of .bss was to get /uninitialized/ variables out
of .data. To quote "A tour through the Unix C compiler" (D. M. Ritchie,
Bell Laboratories, circa 1979)
"BSS means that subsequent information is to be compiled as uninitialized
static data"

[snip]
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Richard Tobin]

The entire purposes of .bss was to get zero-initialized variables out of
.data. In a sense, it's a compression scheme.

[/QUOTE]

IIRC, the entire purpose of .bss was to get /uninitialized/ variables out
of .data. To quote "A tour through the Unix C compiler" (D. M. Ritchie,
Bell Laboratories, circa 1979)
"BSS means that subsequent information is to be compiled as uninitialized
static data"

But "unitialised" static variables are implicitly initialised to zero.
There are no really-uninitialised static variables in C.

Here is a more detailed quote from Ritchie, in the UNIX Assembler
Reference Manual (which I found a copy of at
http://www.tom-yam.or.jp/2238/ref/as.pdf):

The bss segment may not contain any explicitly initialized code or
data. The length of the bss segment (like that of text or data) is
determined by the high-water mark of the location counter within
it. The bss segment is actually an extension of the data segment and
begins immediately after it. At the start of execution of a program,
the bss segment is set to 0. Typically the bss segment is set up by
statements exemplified by

lab:.=.+10

The advantage in using the bss segment for storage that starts
off empty is that the initialization information need not be stored in
the output file.

I think it's clear that references to the bss containing unitialised
variables are meant to imply un-(initialised to non-zero).

-- Richard

 

[Harald van Dijk]

But "unitialised" static variables are implicitly initialised to zero.
There are no really-uninitialised static variables in C.

What about the bytes of a union that are not part of the initialised sub-
object?

 

[Richard Tobin]

But "unitialised" static variables are implicitly initialised to zero.
There are no really-uninitialised static variables in C.

[/QUOTE]

What about the bytes of a union that are not part of the initialised sub-
object?

I suppose so. But you could hardly put them in a different section
from the initialised bytes of the union, so there's still no use for
a really-uninitialised section.

-- Richard

 

[Harald van Dijk]

I suppose so. But you could hardly put them in a different section from
the initialised bytes of the union, so there's still no use for a
really-uninitialised section.

On systems where pointer types or floating-point types are not initialised
to all-bits zero (which are admittedly uncommon, but real), and the
initialised member of the union is of pointer or floating-point type, it
doesn't make sense to put the union in a zero-initialised section.

 

[Richard Tobin]

I suppose so. But you could hardly put them in a different section from
the initialised bytes of the union, so there's still no use for a
really-uninitialised section.

[/QUOTE]

On systems where pointer types or floating-point types are not initialised
to all-bits zero (which are admittedly uncommon, but real), and the
initialised member of the union is of pointer or floating-point type, it
doesn't make sense to put the union in a zero-initialised section.

Quite so. Is there some reason you think I'm disputing that?

If 0.0 is all zeros, then a zero-initialised section can be used
for it. If it's not, then you need something like .data that can
be initialised to any value. Neither case suggests a .bss that is
not initialised at all.

-- Richard

 

[Harald van Dijk]

Quite so. Is there some reason you think I'm disputing that?

If 0.0 is all zeros, then a zero-initialised section can be used for it.
If it's not, then you need something like .data that can be initialised
to any value. Neither case suggests a .bss that is not initialised at
all.

Oh, sure, initialised to whatever random bytes the compiler happened to
have in memory when laying out the .data section or equivalent is
effectively uninitialised to me.

But depending on the number of bytes, it may be a waste of space to store
them all when there's no need to do so. To use an extreme example:

union {
double d;
char a[1000000];
} u;

Is there a benefit in filling a[sizeof(double)] through a[999999] in the
generated object or at startup? The drawback seems obvious to me.
Especially if u.d needs to be filled in the startup code anyway (let's say
because the system doesn't have a .data section or equivalent), I can
imagine the rest of a being semi-random.

 

[Stephen Sprunk]

Oh, sure, initialised to whatever random bytes the compiler happened to
have in memory when laying out the .data section or equivalent is
effectively uninitialised to me.

Uh, what? If all-bits-zero (which is what you'd get in .bss) does not
mean 0.0, then the compiler would instead create an entry in .data that
_does_ mean 0.0. There is no initialization to "whatever random bytes
the compiler happened to have in memory"; either way, the variable will
end up being 0.0.

If the OS does not zero-fill the .bss section on creation, then the
compiler must insert code to correct that before execution began,
eliminating any random bytes that might happened to be in memory. If it
didn't, the C implementation would be non-conforming. However, the need
to do this should be rare since giving a program leftover data from
another program can be a serious security hole.

S

 

[Harald van Dijk]

Uh, what? If all-bits-zero (which is what you'd get in .bss) does not
mean 0.0, then the compiler would instead create an entry in .data that
_does_ mean 0.0. There is no initialization to "whatever random bytes
the compiler happened to have in memory"; either way, the variable will
end up being 0.0.

Given

union {
double d;
char x[1000];
} u = { 0 };

u.d will be initialised to zero, but I was talking about the bytes that
follow u.d.

 

[Stephen Sprunk]

Uh, what? If all-bits-zero (which is what you'd get in .bss) does not
mean 0.0, then the compiler would instead create an entry in .data that
_does_ mean 0.0. There is no initialization to "whatever random bytes
the compiler happened to have in memory"; either way, the variable will
end up being 0.0.

Given

union {
double d;
char x[1000];
} u = { 0 };

u.d will be initialised to zero, but I was talking about the bytes that
follow u.d.

In that example, isn't the part of u.x not overlapping with u.d supposed
to be zero-filled as well?

This example could be inefficient if all-bits-zero wasn't 0.0, forcing
the entire union into .data instead of .bss, but I don't think you'd get
"random bytes" in the non-overlapping part of u.x.

S

 

[jameskuyper]

Harald van D©¦k wrote: ....

Given

union {
double d;
char x[1000];
} u = { 0 };

u.d will be initialised to zero, but I was talking about the bytes that
follow u.d.

In that example, isn't the part of u.x not overlapping with u.d supposed
to be zero-filled as well?

No.