|
2
|
1 |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
|
2 |
"http://www.w3.org/TR/html4/loose.dtd">
|
|
|
3 |
<html><head>
|
|
|
4 |
<title>Examining the call stack in Debugging information</title>
|
|
|
5 |
<link href="sysdoc-eclipse.css" type="text/css" rel="stylesheet" >
|
|
|
6 |
<link href="sysdoc-eclipse.css" type="text/css" rel="stylesheet" >
|
|
|
7 |
<link href="../../book.css" type="text/css" rel="stylesheet" >
|
|
|
8 |
<div class="Head1">
|
|
|
9 |
|
|
|
10 |
<h2>General Points</h2>
|
|
|
11 |
</div>
|
|
|
12 |
<div>
|
|
|
13 |
<p>Tracing the call stack is an advanced use of the
|
|
|
14 |
<a href="CrashDebugger_cmd_m.guide.html" title="The debug monitor and command syntax / m - do a memory dump">m</a> command that
|
|
|
15 |
allows you to <a href="CrashDebuggerExaminingMemory.guide.html" title="Examining memory">examine memory</a>.</p>
|
|
|
16 |
<p>Every time a function is called, the return address is
|
|
|
17 |
automatically saved into register R14 (Link Register). In addition
|
|
|
18 |
to this the return address is generally pushed onto the call stack; it is
|
|
|
19 |
always pushed in debug builds but the push operation is sometimes optimised out
|
|
|
20 |
in release builds. This allows you to trace back through the value of
|
|
|
21 |
R14 and these saved addresses to see the sequence of function
|
|
|
22 |
calls. Unfortunately this is quite tedious to do because the stack is also used
|
|
|
23 |
for automatic variables and other data. You need to work out which values on
|
|
|
24 |
the stack refer to return addresses. </p>
|
|
|
25 |
<p>When you are debugging only ROM-based code, it is relatively easy
|
|
|
26 |
to identify the pushed return addresses because all code addresses will be in
|
|
|
27 |
the ROM range: 0xF800000 to 0xFFEFFFFF for the
|
|
|
28 |
<a href="CrashDebuggerMemoryMap.guide.html" title="Symbian OS memory map / Moving model">moving model</a>. However,
|
|
|
29 |
there is also data in the ROM, which means that an address on the stack which
|
|
|
30 |
is in the ROM range could point to data instead of code. If you want to trace
|
|
|
31 |
applications loaded into RAM, i.e. anything not run from drive Z:, then stack
|
|
|
32 |
tracing is more difficult because the code can move about and RAM-loaded code
|
|
|
33 |
is given an address assigned at load time.</p>
|
|
|
34 |
<p>Note that <a href="CrashDebuggerUsingMAKSYM-Ref.guide.html">using the MAKSYM tool</a> is essential for tracing back through the stack.</p>
|
|
|
35 |
</div>
|
|
|
36 |
<h5>Related tasks</h5>
|
|
|
37 |
<ul>
|
|
|
38 |
<li><a href="CrashDebuggerCallStack.guide03.html">Finding the Stack</a></li>
|
|
|
39 |
<li><a href="CrashDebuggerCallStack.guide04.html">Tracing through the Call Stack Heuristically</a></li>
|
|
|
40 |
<li><a href="CrashDebuggerCallStack.guide05.html">Walking through the Call Stack</a></li>
|
|
|
41 |
</ul>
|
|
|
42 |
<div id="footer">Copyright © 2009 Nokia Corporation and/or its subsidiary(-ies). All rights reserved. <br>License: <a href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</a></div>
|
|
|
43 |
</body>
|
|
|
44 |
</html>
|
|
|
45 |
|