text,data and bss

"c.***********@gmail.com" <c.***********@gmail.comwrites:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Nov 16 '08 #5

James Harris

On 16 Nov, 12:14, "c.lang.mys...@gmail.com" <c.lang.mys...@gmail.com>
wrote:

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.

--
HTH,
James

Nov 16 '08 #6

James Harris

On 16 Nov, 12:18, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:

c.lang.mys...@gmail.com wrote:
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

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?

--
James

Nov 16 '08 #7

James Harris wrote:

On 16 Nov, 12:18, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
>c.lang.mys...@gmail.com wrote:
>>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

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

Nov 16 '08 #8

James Harris <ja************@googlemail.comwrites:

On 16 Nov, 12:18, "Joachim Schmitz" <nospam.j...@schmitz-digital.de>
wrote:
>c.lang.mys...@gmail.com wrote:
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

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Nov 16 '08 #9

Lew Pitcher

On November 16, 2008 11:56, in comp.lang.c, Stephen Sprunk
(st*****@sprunk.org) 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. ------

Nov 16 '08 #10

Richard Tobin

In article <9c***************************@TEKSAVVY.COM-Free>,
Lew Pitcher <le*********@digitalfreehold.cawrote:

>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"

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
--
Please remember to mention me / in tapes you leave behind.

Nov 16 '08 #11

On Sun, 16 Nov 2008 18:47:55 +0000, Richard Tobin wrote:

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?

Nov 16 '08 #12

Richard Tobin

In article <gf**********@news.motzarella.org>,
Harald van DÄ³k <tr*****@gmail.comwrote:

>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?

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

--
Please remember to mention me / in tapes you leave behind.

Nov 16 '08 #13

On Sun, 16 Nov 2008 19:02:54 +0000, Richard Tobin wrote:

In article <gf**********@news.motzarella.org>, Harald van DÄ³k
<tr*****@gmail.comwrote:

>>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?

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.

Nov 16 '08 #14

Richard Tobin

In article <gf**********@news.motzarella.org>,
Harald van DÄ³k <tr*****@gmail.comwrote:

>>>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?

>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.

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
--
Please remember to mention me / in tapes you leave behind.

Nov 16 '08 #15

On Sun, 16 Nov 2008 22:27:37 +0000, Richard Tobin wrote:

In article <gf**********@news.motzarella.org>, Harald van DÄ³k
<tr*****@gmail.comwrote:

>>>>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?

>>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.

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.

Nov 16 '08 #16

Harald van DÄ³k wrote:

On Sun, 16 Nov 2008 22:27:37 +0000, Richard Tobin wrote:
>In article <gf**********@news.motzarella.org>, Harald van DÄ³k
<tr*****@gmail.comwrote:
>>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.

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

Nov 17 '08 #17

On Mon, 17 Nov 2008 00:25:58 -0600, Stephen Sprunk wrote:

Harald van DÄ³k wrote:
>On Sun, 16 Nov 2008 22:27:37 +0000, Richard Tobin wrote:
>>In article <gf**********@news.motzarella.org>, Harald van DÄ³k
<tr*****@gmail.comwrote:
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.

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.

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.

Nov 17 '08 #18

Harald van DÄ³k wrote:

On Mon, 17 Nov 2008 00:25:58 -0600, Stephen Sprunk wrote:
>Harald van DÄ³k wrote:
>>On Sun, 16 Nov 2008 22:27:37 +0000, Richard Tobin wrote:
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.

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

Nov 17 '08 #19

jameskuyper

Stephen Sprunk wrote:

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.

Nov 17 '08 #20

On Mon, 17 Nov 2008 15:27:52 -0600, Stephen Sprunk wrote:

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, it's not, and in the general case, it can't be:

union {
char x[sizeof(double) - 1];
double d;
} u = { 0 };

There isn't any way to zero-initialise the final byte of d. (I'm assuming
sizeof(double) is not 1.)

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.

If real-world compilers don't clear out bits in floating point constants
that don't contribute to the value (admittedly, this is not by a
conforming compiler, but it's not one of the areas in which it doesn't
conform), it wouldn't surprise me if real-world compilers don't clear out
bytes in unions that don't contribute to the value.

Nov 17 '08 #21

James Harris

On 17 Nov, 21:27, Stephen Sprunk <step...@sprunk.orgwrote:

Harald van D©¦k wrote:
On Mon, 17 Nov 2008 00:25:58 -0600, Stephen Sprunk wrote:
Harald van D©¦k wrote:
On Sun, 16 Nov 2008 22:27:37 +0000, Richard Tobin wrote:
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.

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.

I don't think it is possible for C to initialise both components of
the above union to zero - at least not in the general case. Where the
machine has a double zero representation that is not all zero bits it
is impossible to zero both.

James

Nov 17 '08 #22

James Kuyper

jameskuyper wrote:

Stephen Sprunk wrote:
>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.

Sorry - that wasn't meant to be so abrupt - I accidentally sent that
message when I'd just barely started writing it.

6.2.6.1p6: "When a value is stored in an object of structure or union
type, including in a member object, the bytes of the object
representation that correspond to any padding bytes take
unspecified values."

6.2.6.1p7: "When a value is stored in a member of an object of union
type, the bytes of the object representation that do not correspond to
that member but do correspond to other members take unspecified values."

You're probably thinking of the following rule:

6.7.8p21: "... the remainder of the aggregate shall be initialized
implicitly the same as objects that have static storage duration."

However, unions are NOT aggregates, so this rule only applies to
structures or arrays.

Nov 18 '08 #23

lawrence.jones

Stephen Sprunk <st*****@sprunk.orgwrote:

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?

Not so far, but there's a fair chance that C1X will require it.
--
Larry Jones

Kicking dust is the only part of this game we really like. -- Calvin

Nov 18 '08 #24

la************@siemens.com writes:

Stephen Sprunk <st*****@sprunk.orgwrote:
>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?

Not so far, but there's a fair chance that C1X will require it.

Really? How will something like this be handled?

union {
int i;
double d;
};

Suppose sizeof(double) sizeof(int), and double(0.0) isn't
represented as all-bits-zero.

Or consider:

union {
int i;
float f;
void *p;
}

Which member gets zeroed? Will this apply only to non-overlapping
members? (Obviously all top-level members overlap; this can apply
only to submembers.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Nov 18 '08 #25

Keith Thompson wrote:

la************@siemens.com writes:
>Stephen Sprunk <st*****@sprunk.orgwrote:
>>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?

Not so far, but there's a fair chance that C1X will require it.

Really? How will something like this be handled?

union {
int i;
double d;
};

Suppose sizeof(double) sizeof(int), and double(0.0) isn't
represented as all-bits-zero.

If you are initializing d, nothing would change since there is no
non-overlapping part of i.

In the case where sizeof(int) sizeof(double), then the non-overlapping
bytes in i would be zero-filled. That is, in fact, what happens with
every implementation I've used (since they zero-fill all memory before
giving it to a process), which is part of why I had thought it was
required. (The is that I rarely use unions, so I keep thinking of the
rules for structs, which are similar but not identical.)

Or consider:

union {
int i;
float f;
void *p;
}

Which member gets zeroed? Will this apply only to non-overlapping
members? (Obviously all top-level members overlap; this can apply
only to submembers.)

See above. The proposed change would only affect the non-overlapping
parts of members that weren't explicitly initialized.

S

Nov 19 '08 #26