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

[CBFalconer]

sidd wrote:

Richard Heathfield <[e-mail].i nvalidwrote:

>Keith Thompson said:

>>sidd <siddharthku... @gmail.comwrite s:

[...]

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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Kenny McCormack]

In article <H%************ *****@newsfe01. iad>,
Chris M. Thomasson <[e-mail] dwrote:
....

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

[CBFalconer]

"Chris M. Thomasson" wrote:

"Antoninus Twink" <no****@nospam. invalidwrote in message

>sidd wrote:

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

Twink is a pure troll. Please don't encourage him/her/it.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Antoninus Twink]

On 10 Aug 2008 at 12:15, Chris M. Thomasson wrote:

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

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

I suggest no such thing. I simply point out that that is what happens on
Linux/x86, which is what the OP asked about.

[Stephen Sprunk]

sidd wrote:

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.

<OT>
Automatic variables do not exist in the executable file, in the sense
that you seem to be meaning. They are created on the stack at runtime
as needed, assuming the compiler doesn't put them into registers or
completely optimize them away. Globals and statics can be put in a
fixed part of the executable, since exactly one copy of them will exist
for the entire duration of the program, but that is not true of
automatic variables. Think about recursion in particular; each instance
of the function needs its own copy of any automatic variables.

How a stack frame is created will vary depending on the particular
processor and perhaps OS that you are using. The best thing you can do
is direct your compiler to produce unoptimized assembly code instead of
an executable (e.g. gcc -S -O0) and try to understand the output. On
every system I'm aware of, each function will have a standard "prologue"
at the beginning and "epilogue" at the end. These are what set up and
destroy the stack frame, among other things. If the compiler needs
space on the stack for automatic variables, you will see a small
variation in those two sections to account for the extra space needed.
</OT>

S

[Flash Gordon]

Antoninus Twink wrote, On 10/08/08 14:29:

On 10 Aug 2008 at 12:15, Chris M. Thomasson wrote:

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

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

I suggest no such thing. I simply point out that that is what happens on
Linux/x86, which is what the OP asked about.

The OP asked about Linux, not necessarily Linux on an x86, and I have a
desktop Linux box where the stack grows up.
--
Flash Gordon