which called the function, but the return address for the called function is the address of
the instruction following the function call instruction. On some machine architectures, it
can be difficult to determine the address of the instruction which called a function,
because all that is saved in the called frame is the return address; if a machine has
variable length instructions, it is difficult (in general) to work backwards from the return
address to find the previous instruction.
The depth of the call stack (i.e., the number of call frames on the call stack) depends on
how many nested function calls have occurred since the thread began execution. The
bottom of the call stack is the oldest call frame on the call stack, and represents the call
frame where execution began for the currently executing thread. For the main thread of
the process, this is usually a frame that is set up by an assembly language startup routine
that then (directly or indirectly) calls the “main” function of the program. For other
threads, it will be the stack frame set up by the operating system when the thread is
created via some operating system routine. Identifying the bottom frame of a call stack is
often difficult, because the normal conventions for storing return addresses do not apply
to such frames but there is generally no way for the stack analysis routines to know that;
as a result they may obtain a spurious return address that leads to one or more bogus stack
frames (i.e., frames that do not really exist). This is one area of the current call stack
analysis that might be improved by making calls into the TOS component to determine if
there are operating-system-dependent ways of identifying the bottom of the call stack.
A list of the call frames in a call stack is sometimes called a back trace, since it traces
backwards the sequence of functions which were called in order to reach this point in the
execution of the thread. To produce a back trace and allow the user to evaluate and
manipulate variables and arguments for older call frames, the DFW needs at least to find
the base address for each call frame; given that and a knowledge of how arguments and
local variables are stored relative to the call frame of a particular function (which is
obtained from the symbolic debugging information included in the ELF file), the DFW
can determine the values of most variables and arguments. There are two special cases
that add complications to this:
1. The return address is almost always stored somewhere in the call frame, and we
need to determine how to find it.
2. The compiler may have assigned some variables to registers, so we may need to
determine how to find the value of a register in a particular call frame.
Both of these cases will be discussed in much greater detail below.
3 The Structure of the Call Frame
Every machine architecture that provides an implementation of C or C++ must provide an
area of memory that can be used for the call stack during the execution of the generated
code. A given call frame is identified by an address of a block of memory on the stack.
This address is referred to as the canonical frame address, or CFA, for the called
function. The CFA for a particular frame is a logical address and may point to either the
raw.doc Page 5 of 47
10
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
11
