3

I've been going through some Unix text books and I can't have a clear picture on the contents of the stack area of the process. Can anyone please explain or point out some references?

4

You only get a clear picture of the stack just as the kernel hands off to ld.so, the dynamic linker. You can find a basic picture here. That shows argc, argv and envp, the traditional 3 arguments to a C program's int main(int argc, char **argv, char **envp).

That view is somewhat simplistic. An ELF auxiliary vector exists on the stack, too, and conveys a lot of information to ld.so

After ld.so runs, the libc runtime steps in and complicates things. C++ constructors can be run, all kinds of crazy stuff can end up on the stack. It depends on what compiled the program. Even simple C programs can do different things based on what library they got compiled with.

1

This wikipedia article is fairly concise. If you google "stack vs. heap" you'll find a ton of stuff; generally they are explained in relation to one another.

If you don't do any programming, this is not a particularly useful or important thing for you to understand. If you do, then it is; one place most people first encounter the significance of the stack is WRT recursive calls; a more detailed wikipedia article relevant to this regards the call stack. The call stack is what occupies the "stack area of a process"; it holds data local to function calls, and data for nested or recursive function calls are "stacked" on top of each other in LIFO ordering.

If you haven't done any programming in a language that allows for direct memory addressing (e.g. C/C++), understanding how memory addresses map regions of memory is important, hopefully your textbooks have already been through this.

1

Programs typically push function arguments onto the stack, before using the asm CALL instruction to call the function, which pushes the return address onto the stack, so that the RET instruction can later pop it back off and know where to return to. A function also will typically place its local variables on the stack. The calling function also may push any registers it is using onto the stack before making a call so it can pop them back after the called function has used those registes for something else.

A visual representation of the words on the stack where functionA has called functionB might look like this:

local1
arg1
functionA+12
local1
local2

Here functionA had a local variable, and then passed an argument to functionB, and stored the return address ( 12 bytes after the start of functionA ). Then functionB put two of its own local variables on the stack. If functionB calls functionC, then the stack continues to grow, and then it shrinks again as functions return.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.