From The Linux Programming Interface:

enter image description here

  1. Where is the kernel stack (mentioned in the quote below) in the above diagram?

    Is it the top part "Kernel (mapped into process virtual memory, but no accessilto program)" in the above diagram?

    the term user stack is used to distinguish the stack we describe here from the kernel stack. The kernel stack is a per-process memory region maintained in kernel memory that is used as the stack for execution of the functions called internally during the execution of a system call. (The kernel can’t employ the user stack for this purpose since it resides in unprotected user memory.)

  2. Where are "Frames for C run-time startup functions" and "Frame for main()" (mentioned from the diagram below) in the above diagram?

    Is "argv, environ" in the above diagram "Frames for C run-time startup functions", "Frame for main()", or part of either?

    enter image description here

  3. What is the lowest segment between 0x00000000 and 0x08048000 used for?


  • That is not a complete diagram, bear in mind. auxv is missing; application-space memory for the stacks of other threads is missing; and heap allocated with mmap rather than sbrk is missing.
    – JdeBP
    Sep 3 '18 at 10:34
  • can you show me the complete diagram? Thanks.
    – Tim
    Sep 3 '18 at 13:02
  1. There is not a kernel stack. For each thread, there is a memory region that is used as stack space when the process makes a system call. There are also separate "interrupt stacks", one per CPU, which are used by the interrupt handler. These memory areas reside in the kernel address space (above 0xc0000000 in your figure.

  2. The stack frames (C runtime frames, the frame for main, etc.) are part of the stack. The process arguments (argv) and the environment are separate areas, and are not part of the stack.

  3. The area between 0x0 and 0x08048000 (about 128 MB) is not used for anything. Originally, the i386 System V ABI reserved this area for the stack, but Linux does things differently. Leaving the area unused does not waste RAM, only address space, because the area is not mapped. Note that this information is almost totally obsolete by now, since it describes how things are done on the 32-bit x86 architecture. 32-bit only x86 machines are hard to find today, and distributions are phasing out support for them.

  • Thanks. In "There is not a kernel stack" and "These memory areas reside in the kernel address space (above 0xc0000000 in your figure", (1) do you mean the kernel stack for the process by "These memory areas"? (2) do you mean the kernel stack for the process is the area named "Kernel (mapped into process virtual memory, but no accessilto program)" above 0xc0000000 in the figure?
    – Tim
    Sep 2 '18 at 16:45
  • For each process (actually thread), there exists a 8 kB memory region that is used for the kernel mode stack for the thread. The stack pointer is switched to point to this region when the thread does a system call. These per-thread memory regions reside within the address space reserved for the kernel, 0xc0000000 to 0xffffffff. This area of course contains a lot of other things; the kernel code for a start. Sep 2 '18 at 17:34
  • 1
    @sourcejedi Ok, this is debatable. On the one hand, the program stack contains "return addresses, parameters, and local variables of the function being executed." The environment strings don't fall into this category. On the other hand, the environment, the program arguments and the program stack are all contained in the same memory region. Sep 2 '18 at 18:53
  • Sorry, I read too quickly, I didn't even notice the diagram showed envp and argv. And the debatable part was not really part of the question. I tend to think in terms of the stack memory region (and I don't think about what a stack frame is very often).
    – sourcejedi
    Sep 2 '18 at 19:55

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.