Differences between revisions 2 and 3
Revision 2 as of 2013-08-29 18:37:31
Size: 3446
Comment: Missing image restored
Revision 3 as of 2013-08-29 18:42:55
Size: 3302
Comment: Did footnote properly
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
''This page was produced by an automated import process, and may have formatting errors; feel free to fix.''
Line 44: Line 42:
In each stack frame, offset 0 from the stack pointer is the frame pointer of the previous frame and offset 4 (this is illustrating a 32-bit architecture) from the stack pointer is the return address. Local variables are indexed from the frame pointer, with negative indexes. In the function {{{fact}}}, offset -4 from the frame pointer is the argument ''n''. In the {{{main}}} function, offset -4 from the frame pointer is the local variable ''i'' and offset -8 from the frame pointer is the local variable ''f'' [DOCF5 5]. In each stack frame, offset 0 from the stack pointer is the frame pointer of the previous frame and offset 4 (this is illustrating a 32-bit architecture) from the stack pointer is the return address. Local variables are indexed from the frame pointer, with negative indexes. In the function {{{fact}}}, offset -4 from the frame pointer is the argument ''n''. In the {{{main}}} function, offset -4 from the frame pointer is the local variable ''i'' and offset -8 from the frame pointer is the local variable ''f'' <<FootNote(This is a simplified example for illustrative purposes only. Good optimizing compilers would not put anything on the stack for such simple functions. Indeed they might eliminate the recursion and use of the stack entirely!)>>.
Line 48: Line 46:
The main GDB data structure describing frames is {{{struct frame_info}}}. It is not used directly, but only via its accessor functions. {{{frame_info}}} includes information about the registers in the frame and a pointer to the code of the function with which the frame is associated. The entire stack is represented as a linked list of {{{frame_info}}} structs.     The main GDB data structure describing frames is {{{struct frame_info}}}. It is not used directly, but only via its accessor functions. {{{frame_info}}} includes information about the registers in the frame and a pointer to the code of the function with which the frame is associated. The entire stack is represented as a linked list of {{{frame_info}}} structs.
Line 50: Line 48:
==== Footnotes ==== == Footnotes ==
Line 52: Line 50:
    === [FOOT5 (5)] ===

 

This is a simplified example for illustrative purposes only. Good optimizing compilers would not put anything on the stack for such simple functions. Indeed they might eliminate the recursion and use of the stack entirely!
<<FootNote>>

All About Stack Frames

GDB needs to understand the stack on which local (automatic) variables are stored. The area of the stack containing all the local variables for a function invocation is known as the stack frame for that function (or colloquially just as the frame). In turn the function that called the function will have its stack frame, and so on back through the chain of functions that have been called.

Almost all architectures have one register dedicated to point to the end of the stack (the stack pointer). Many have a second register which points to the start of the currently active stack frame (the frame pointer). The specific arrangements for an architecture are a key part of the ABI.

A diagram helps to explain this. Here is a simple program to compute factorials:

#include <stdio.h>
int fact (int n)
{
  if (0 == n)
    {
      return 1;
    }
  else
    {
      return n * fact (n - 1);
    }
}

main ()
{
  int i;

  for (i = 0; i < 10; i++)
    {
      int   f = fact (i);
      printf ("%d! = %d\n", i, f);
    }
}

Consider the state of the stack when the code reaches line 6 after the main program has called fact (3). The chain of function calls will be main (), fact (3), fact (2), fact (1) and fact (0).

In this illustration the stack is falling (as used for example by the OpenRISC 1000 ABI). The stack pointer (SP) is at the end of the stack (lowest address) and the frame pointer (FP) is at the highest address in the current stack frame. The following diagram shows how the stack looks.

  • example stack frame

In each stack frame, offset 0 from the stack pointer is the frame pointer of the previous frame and offset 4 (this is illustrating a 32-bit architecture) from the stack pointer is the return address. Local variables are indexed from the frame pointer, with negative indexes. In the function fact, offset -4 from the frame pointer is the argument n. In the main function, offset -4 from the frame pointer is the local variable i and offset -8 from the frame pointer is the local variable f 1.

It is very easy to get confused when examining stacks. GDB has terminology it uses rigorously throughout. The stack frame of the function currently executing, or where execution stopped is numbered zero. In this example frame #0 is the stack frame of the call to fact (0). The stack frame of its calling function (fact (1) in this case) is numbered #1 and so on back through the chain of calls.

The main GDB data structure describing frames is struct frame_info. It is not used directly, but only via its accessor functions. frame_info includes information about the registers in the frame and a pointer to the code of the function with which the frame is associated. The entire stack is represented as a linked list of frame_info structs.

Footnotes

  1. This is a simplified example for illustrative purposes only. Good optimizing compilers would not put anything on the stack for such simple functions. Indeed they might eliminate the recursion and use of the stack entirely! (1)

None: Internals All-About-Stack-Frames (last edited 2013-08-29 18:42:55 by JeremyBennett)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.