where do the automatic variables go ?

[sidd]

In the following code:

int i = 5; ---> it goes to .data segment
int j; ---> it goes to bss segment


int main()
{
int c;
int i = 5; ---> stack
int j[5] = new int[5]; ----> heap
c = i*2; ----> goes to .text segment



}


My question is : When the object file is created there are text, data
and bss segments etc...but there is notthing like stack and heap
segment, what happens to these automatic variables ?

I hope I am making sense.....


Siddharth

 

[santosh]

In the following code:

int i = 5; ---> it goes to .data segment

Not necessarily.

int j; ---> it goes to bss segment

Not necessarily.

int main()
{
int c;
int i = 5; ---> stack

Not necessarily.

int j[5] = new int[5]; ----> heap

This is a syntax error in C. If your doing C++ the note that there is a
specialised group for it: comp.lang.c++.

c = i*2; ----> goes to .text segment

Not necessarily.

}


My question is : When the object file is created there are text, data
and bss segments etc...but there is notthing like stack and heap
segment, what happens to these automatic variables ?

I hope I am making sense.....

Firstly, as far as Standard C is concerned, there need be no segments of
any kind at all. In fact, the format of the final executable image
produced by the last translation phase is not specified at all. In
fact, an interpreter that never produces a machine language
representation is also perfectly legal.

The segments you have mentioned are a common system of laying out
executable files, but this is not universal, and even within the
overall scheme, there is a lot of variation in detail.

In general though, automatic objects are placed in some kind of "stack
like" memory (which under most implementations happens to be an actual
hardware assisted stack), while static objects reside elsewhere. The
compiler may also decide to place string literals and const qualified
objects in read-only storage, while memory returned by
malloc/calloc/realloc is usually from the so-called "heap", though
again it must be emphasised that C itself does not require such
classification, though it is commonly used.

For example a C implementation that decides to place all objects on the
heap is perfectly conforming, while one that decides to allocate all
objects on a stack is also perfectly conforming.

To get a more satisfactory answer (though it is not a generic one), you
must examine the details of your implementation, the memory model used
by your operating system, the format of the executable that your
implementation produces etc. An assembly language group might be a
better idea since these sorts of machine level details are often dealt
with there. See comp.lang.asm.x86 if your system is an x86 based one,
or alt.lang.asm for other architectures. If your system is an embedded
one see comp.arch.embedded.

 

[sidd]

sidd said:

In the following code:

int i = 5;  ---> it goes to .data segment
int j;        ---> it goes to bss segment

The C Standard doesn't guarantee this. Nor does it even require that
implementations recognise the concept of .data or bss segments.

int main()
{
int c;
int i = 5; ---> stack

The C Standard doesn't guarantee this. Nor does it even require that
implementations recognise the concept of a (hardware) stack.

int j[5] = new int[5]; ----> heap

In C, this is just a syntax error.

If you have questions about the C++ language, ask in comp.lang.c++.
If you have questions about the storage techniques used by your
implementation, ask in a group devoted to that implementation.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Can someone please answer the question assuming that it was run on a
linux m/c and the executable was a.out.

 

[Bartc]

In the following code:

int i = 5; ---> it goes to .data segment
int j; ---> it goes to bss segment


int main()
{
int c;
int i = 5; ---> stack
int j[5] = new int[5]; ----> heap
c = i*2; ----> goes to .text segment



}


My question is : When the object file is created there are text, data
and bss segments etc...but there is notthing like stack and heap
segment, what happens to these automatic variables ?

The stack and heap areas are not needed in the executable. They are setup at
runtime. That's if they will exist at all.

 

[santosh]

sidd said:

In the following code:

int i = 5;  ---> it goes to .data segment
int j;        ---> it goes to bss segment

The C Standard doesn't guarantee this. Nor does it even require that
implementations recognise the concept of .data or bss segments.

int main()
{
int c;
int i = 5; ---> stack

The C Standard doesn't guarantee this. Nor does it even require that
implementations recognise the concept of a (hardware) stack.

int j[5] = new int[5]; ----> heap

In C, this is just a syntax error.

If you have questions about the C++ language, ask in comp.lang.c++.
If you have questions about the storage techniques used by your
implementation, ask in a group devoted to that implementation.

<snip>

Can someone please answer the question assuming that it was run on a
linux m/c and the executable was a.out.

<http://althing.cs.dartmouth.edu/secref/resources/lect2.txt>
<http://www.iecc.com/linker/>
<http://en.wikipedia.org/wiki/Executable_and_Linkable_Format>
<http://dirac.org/linux/gdb/02a-Memory_Layout_And_The_Stack.php>

 

[Antoninus Twink]

int main()
{
int c;
int i = 5; ---> stack
int j[5] = new int[5]; ----> heap
c = i*2; ----> goes to .text segment
}

This is a misleading dichotomy. The new line will almost certainly
generate instructions too, which will be placed in the .text segment:
new needs to call malloc() to get its memory, which will indeed be taken
from the heap.

My question is : When the object file is created there are text, data
and bss segments etc...but there is notthing like stack and heap
segment, what happens to these automatic variables ?

The kernel provides each process with a virtual address space, and takes
responsibility for mapping this to physical memory. When your C program
has been loaded and starts executing, the operating system
(executable-loader) has kindly set up this address space to look like
this:


highest address
=========
| |
| |
| |
| |
| |
| |
=========
| data |
| +bss |
=========
| text |
=========
address 0

As you program starts generating stack frames and automatic variables,
the stack grows downwards from high to low memory addresses. Meanwhile,
the heap starts growing upwards from above the data segment.

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

Things get more interesting when you add libraries, threads etc. into
the mix, but this is the basic setup.

 

[sidd]

int main()
{
int c;
int i = 5; ---> stack
int j[5] = new int[5]; ----> heap
c = i*2; ----> goes to .text segment
}

This is a misleading dichotomy. The new line will almost certainly
generate instructions too, which will be placed in the .text segment:
new needs to call malloc() to get its memory, which will indeed be taken
from the heap.

My question is : When the object file is created there are text, data
and bss segments etc...but there is notthing like stack and heap
segment,  what happens to these automatic variables ?

The kernel provides each process with a virtual address space, and takes
responsibility for mapping this to physical memory. When your C program
has been loaded and starts executing, the operating system
(executable-loader) has kindly set up this address space to look like
this:

highest address
  =========
  |       |
  |       |
  |       |
  |       |
  |       |
  |       |
  =========
  | data  |
  | +bss  |
  =========
  | text  |
  =========
address 0

As you program starts generating stack frames and automatic variables,
the stack grows downwards from high to low memory addresses. Meanwhile,
the heap starts growing upwards from above the data segment.

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

Things get more interesting when you add libraries, threads etc. into
the mix, but this is the basic setup.

Thanks for the wonderful links and explanations, but I guess my
question still remains unanswered. My question was that when the code
is compiled and converted to a.out, what happens to the automatic
variables, in other words can someone elaborate more about the
generation of stack frames. I understand that whenever a function is
called, a stack frame gets generated but how are the details of that
routine laid out in the a.out file. In other words where do the
automatic variables part of the routine lie in the a.out format.


Thanks,
Sidd

 

[Bartc]

int main()
{
int c;
int i = 5; ---> stack
int j[5] = new int[5]; ----> heap
c = i*2; ----> goes to .text segment
}

called, a stack frame gets generated but how are the details of that
routine laid out in the a.out file. In other words where do the
automatic variables part of the routine lie in the a.out format.

If you get your compiler to display intermediate asm code, you will see how
automatic variables are handled.

For example, in the following function:

void foo(void) {
int a,b,c;
a=b+c;
}

the auto variables a,b,c are handled as offsets -4, -8, -12 to some stack
space obtained at runtime:

foo:
push ebp
mov ebp,esp
sub esp,12 ;allocate stack frame of 12 bytes

mov eax,[ebp-8] ;<b>
add eax,[ebp-12] ;<c>
mov [ebp-4],eax ;<a>

add esp,12 ;free the 12 bytes
pop ebp
retn

The details will of course vary greatly between machines and compilers.

 

[Antoninus Twink]

Thanks for the wonderful links and explanations, but I guess my
question still remains unanswered. My question was that when the code
is compiled and converted to a.out, what happens to the automatic
variables, in other words can someone elaborate more about the
generation of stack frames. I understand that whenever a function is
called, a stack frame gets generated but how are the details of that
routine laid out in the a.out file. In other words where do the
automatic variables part of the routine lie in the a.out format.

Firstly, it's perhaps worth clarifying that although most C compilers
produce a file called a.out if you don't specify an output filename,
this is purely for historical reasons, and this executable need not be
in a.out format. You mentioned Linux in another post... unless you're
using a kernel that's older than version 1.2 or so, the native format
will be ELF.

As to the question about stack frames, this was explain very clearly by
Jacob Navia, one of the real C experts in this group and the creator of
a C99 compiler for Windows, a few months ago: check out his post and ask
if you have any questions.

<http://groups.google.com/group/comp.lang.c/browse_thread/thread/b3242e1e28fa20a7/93b39ea87b317fa6>

 

[Keith Thompson]

sidd said:

In the following code:

int i = 5;  ---> it goes to .data segment
int j;        ---> it goes to bss segment

The C Standard doesn't guarantee this. Nor does it even require that
implementations recognise the concept of .data or bss segments.

int main()
{
int c;
int i = 5; ---> stack

The C Standard doesn't guarantee this. Nor does it even require that
implementations recognise the concept of a (hardware) stack.

int j[5] = new int[5]; ----> heap

In C, this is just a syntax error.

If you have questions about the C++ language, ask in comp.lang.c++.
If you have questions about the storage techniques used by your
implementation, ask in a group devoted to that implementation.

<snip>

Can someone please answer the question assuming that it was run on a
linux m/c and the executable was a.out.

I'm sure someone can.

Richard gave you a complete and correct answer with regard to C.
If you want a system-specific answer, you'll have to ask in a
system-specific newsgroup, probably one of the comp.os.linux.* groups

 

[Keith Thompson]

Thanks for the wonderful links and explanations, but I guess my
question still remains unanswered. My question was that when the code
is compiled and converted to a.out, what happens to the automatic
variables, in other words can someone elaborate more about the
generation of stack frames. I understand that whenever a function is
called, a stack frame gets generated but how are the details of that
routine laid out in the a.out file. In other words where do the
automatic variables part of the routine lie in the a.out format.

This really is the wrong place to ask. ("Antoninus Twink" knows this
perfectly well; he's a troll.)

Your question isn't about the C language, which is what this newsgroup
discusses. Your question is about the behavior of programs under
Linux. If you post to a Linux newsgroup, you'll find lots of experts
who can answer your question better than anyone here can, and others
who will gleefully correct any errors the first round of experts might
make.

 

[Richard]

sidd said:
In the following code:

int i = 5;  ---> it goes to .data segment
int j;        ---> it goes to bss segment

The C Standard doesn't guarantee this. Nor does it even require that
implementations recognise the concept of .data or bss segments.

int main()
{
int c;
int i = 5; ---> stack

The C Standard doesn't guarantee this. Nor does it even require that
implementations recognise the concept of a (hardware) stack.

int j[5] = new int[5]; ----> heap

In C, this is just a syntax error.

If you have questions about the C++ language, ask in comp.lang.c++.
If you have questions about the storage techniques used by your
implementation, ask in a group devoted to that implementation.

<snip>

Can someone please answer the question assuming that it was run on a
linux m/c and the executable was a.out.

I'm sure someone can.

Someone already did. Someone in this group who knew the subject.

Richard gave you a complete and correct answer with regard to C.
If you want a system-specific answer, you'll have to ask in a
system-specific newsgroup, probably one of the comp.os.linux.* groups

No. He didn't. Someone answered him very well here.

 

[sidd]

Keith Thompson said:








In *this* group, however, such errors will not be corrected, partly because
many of us don't even read Mr Twink's articles any more, and partly
because many of us respect the topicality conventions of the group so
we're not going to start talking about executable image formats just
because someone asks.

To the OP: Given that "Antoninus Twink" has a track record of being badly
wrong on technical issues, it would be in your own best interest to get a
response from a system expert in a group full of experts in that same
system. The trouble with Twink is that, unless you already know the
subject yourself very well indeed, it isn't always easy to tell whether
he's right or wrong. And since you had to ask the question, you don't know
the subject very well indeed, right? So you have two choices - believe a
response given by someone known to be technically unreliable, or ask the
question in a group where the subject of the question is topical, so that
the experts can apply the group correction mechanism appropriately.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999- Hide quoted text -

- Show quoted text -

Thanks all for your suggestions and answers, but I guess I am still
not getting the explanation I am looking for so I will go ahead
and post this on one of the linux forums

 

[Antoninus Twink]

To the OP: Given that "Antoninus Twink" has a track record of being badly
wrong on technical issues, it would be in your own best interest to get a
response from a system expert in a group full of experts in that same
system. The trouble with Twink is that, unless you already know the
subject yourself very well indeed, it isn't always easy to tell whether
he's right or wrong.

If there is a technical error in anything I post, then point it out. But
no, all you can do is sit at the sidelines slinging mud, isn't it?

To the OP: before deciding how seriously to take Mr "Heathfield"'s slurs
against me, you might like to know that he says even worse things about
the technical competence of Jacob Navia. Jacob is one of the group's
most helpful posters, and has also WRITTEN A C COMPILER for Windows. But
according to Heathfield, Jacob knows nothing about C. In that case I'm
proud to be tarred with the same brush as Jacob.

What makes Heathfield twist reality in this way? That's a question for a
psychologist, really, but it seems clear that he's an egomaniac who
wants to be in charge of this group, and force it to follow his own very
strict definition of topicality. Just look at this thread - the
executable output by a C compiler is apparently "off topic" in a C
newsgroup! It's just nonsense.

So, an egomaniac, and probably quite a big chunk of jealousy that his
arch-enemy Jacob has actually got off his fanny and done something
useful for the C community by writing and maintaining a free compiler
and IDE, whereas Heathfield for all his posturing and blustering has
done little more than tell a thousand newbies what the correct return
type of main() is. If you ever wonder what happens to schoolyard bullies
when they grow up, just look at Heathfield.

 

[Antoninus Twink]

Thanks all for your suggestions and answers, but I guess I am still
not getting the explanation I am looking for so I will go ahead
and post this on one of the linux forums

The post by Jacob Navia that I linked to provides an excellent answer to
the question that you asked. So if you didn't get the information you
wanted out of it, then you'll need to phrase your question more
precisely. (Whether you post it here, or allow the group's bullies to
push you off somewhere else).

 

[CBFalconer]

Keith Thompson said:

[...]

Thanks for the wonderful links and explanations, but I guess my
question still remains unanswered. My question was that when the code
is compiled and converted to a.out, what happens to the automatic
variables, in other words can someone elaborate more about the
generation of stack frames. I understand that whenever a function is
called, a stack frame gets generated but how are the details of that
routine laid out in the a.out file. In other words where do the
automatic variables part of the routine lie in the a.out format.

This really is the wrong place to ask. ("Antoninus Twink" knows
this perfectly well; he's a troll.)

Your question isn't about the C language, which is what this
newsgroup discusses. Your question is about the behavior of
programs under Linux. If you post to a Linux newsgroup, you'll
find lots of experts who can answer your question better than
anyone here can, and others who will gleefully correct any
errors the first round of experts might make.

In *this* group, however, such errors will not be corrected,
partly because many of us don't even read Mr Twink's articles any
more, and partly because many of us respect the topicality
conventions of the group so we're not going to start talking about
executable image formats just because someone asks.

To the OP: Given that "Antoninus Twink" has a track record of
being badly wrong on technical issues, it would be in your own
best interest to get a response from a system expert in a group
full of experts in that same system. The trouble with Twink is
that, unless you already know the subject yourself very well
indeed, it isn't always easy to tell whether he's right or wrong.
And since you had to ask the question, you don't know the subject
very well indeed, right? So you have two choices - believe a
response given by someone known to be technically unreliable, or
ask the question in a group where the subject of the question is
topical, so that the experts can apply the group correction
mechanism appropriately.

Thanks all for your suggestions and answers, but I guess I am still
not getting the explanation I am looking for so I will go ahead
and post this on one of the linux forums

If you just bothered to read the responses you did get, and quoted
above, you will find out why this is the wrong place to ask. And
you want more than just a linux group, you want one that deals with
your actual machine. Linux runs on many widely differing
computers.

 

[Chris M. Thomasson]

int main()
{
int c;
int i = 5; ---> stack
int j[5] = new int[5]; ----> heap
c = i*2; ----> goes to .text segment
}

This is a misleading dichotomy. The new line will almost certainly
generate instructions too, which will be placed in the .text segment:
new needs to call malloc() to get its memory, which will indeed be taken
from the heap.

My question is : When the object file is created there are text, data
and bss segments etc...but there is notthing like stack and heap
segment, what happens to these automatic variables ?

The kernel provides each process with a virtual address space, and takes
responsibility for mapping this to physical memory. When your C program
has been loaded and starts executing, the operating system
(executable-loader) has kindly set up this address space to look like
this:


highest address
=========
| |
| |
| |
| |
| |
| |
=========
| data |
| +bss |
=========
| text |
=========
address 0

As you program starts generating stack frames and automatic variables,
the stack grows downwards from high to low memory addresses.

[...]

You act as if the stack will always grow downwards; why?

http://groups.google.com/group/comp.arch/search?hl=en&group=comp.arch&q=stack+growth

Meanwhile, the heap starts growing upwards from above the data segment.

You seem to suggest that platforms are forced to do such a thing; why?

 

[Chris M. Thomasson]

int main()
{
int c;
int i = 5; ---> stack
int j[5] = new int[5]; ----> heap
c = i*2; ----> goes to .text segment
}

This is a misleading dichotomy. The new line will almost certainly
generate instructions too, which will be placed in the .text segment:
new needs to call malloc() to get its memory, which will indeed be taken
from the heap.

[...]

Umm. NO, because I have created a 100% conforming malloc impl for an
embedded system with no heap:

http://groups.google.com/group/comp.lang.c++.moderated/msg/ef7314c3f55495ac

 

[Chris M. Thomasson]

int main()
{
int c;
int i = 5; ---> stack
int j[5] = new int[5]; ----> heap
c = i*2; ----> goes to .text segment
}

This is a misleading dichotomy. The new line will almost certainly
generate instructions too, which will be placed in the .text segment:
new needs to call malloc() to get its memory, which will indeed be taken
from the heap.

[...]

Umm. NO, because I have created a 100% conforming malloc impl for an
embedded system with no heap:

http://groups.google.com/group/comp.lang.c++.moderated/msg/ef7314c3f55495ac

100% stack-based malloc is possible, even in the presence of
multi-threading. If you want to discuss the algorithm I created, post over
on comp.programming.threads.

 

[Kenny McCormack]

100% stack-based malloc is possible, even in the presence of

Um, er, you just used the "S-word" in public. Please go and wash your
mouth out with soap.

I expect Mr. Keith to come along any moment now (almost certainly within
the hour) to state that C has no stack. So, therefore, you can't
possibly have written something in C that uses a stack.

It must have been in some other, irrelevant, "C-like" language.
Maybe AWK? Maybe Perl?