diff -r bf9a2104bee6 -r 5d016a880824 debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerCallStack.guide02.html --- a/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerCallStack.guide02.html Thu Feb 18 14:39:30 2010 -0600 +++ b/debuggercdi/com.nokia.carbide.cpp.debug.crashdebugger/html/DebuggingInformation/CrashDebuggerCallStack.guide02.html Thu Feb 18 15:11:20 2010 -0600 @@ -1,45 +1,45 @@ - -
-Tracing the call stack is an advanced use of the -m command that -allows you to examine memory.
-Every time a function is called, the return address is -automatically saved into register R14 (Link Register). In addition -to this the return address is generally pushed onto the call stack; it is -always pushed in debug builds but the push operation is sometimes optimised out -in release builds. This allows you to trace back through the value of -R14 and these saved addresses to see the sequence of function -calls. Unfortunately this is quite tedious to do because the stack is also used -for automatic variables and other data. You need to work out which values on -the stack refer to return addresses.
-When you are debugging only ROM-based code, it is relatively easy -to identify the pushed return addresses because all code addresses will be in -the ROM range: 0xF800000 to 0xFFEFFFFF for the -moving model. However, -there is also data in the ROM, which means that an address on the stack which -is in the ROM range could point to data instead of code. If you want to trace -applications loaded into RAM, i.e. anything not run from drive Z:, then stack -tracing is more difficult because the code can move about and RAM-loaded code -is given an address assigned at load time.
-Note that using the MAKSYM tool is essential for tracing back through the stack.
-Tracing the call stack is an advanced use of the +m command that +allows you to examine memory.
+Every time a function is called, the return address is +automatically saved into register R14 (Link Register). In addition +to this the return address is generally pushed onto the call stack; it is +always pushed in debug builds but the push operation is sometimes optimised out +in release builds. This allows you to trace back through the value of +R14 and these saved addresses to see the sequence of function +calls. Unfortunately this is quite tedious to do because the stack is also used +for automatic variables and other data. You need to work out which values on +the stack refer to return addresses.
+When you are debugging only ROM-based code, it is relatively easy +to identify the pushed return addresses because all code addresses will be in +the ROM range: 0xF800000 to 0xFFEFFFFF for the +moving model. However, +there is also data in the ROM, which means that an address on the stack which +is in the ROM range could point to data instead of code. If you want to trace +applications loaded into RAM, i.e. anything not run from drive Z:, then stack +tracing is more difficult because the code can move about and RAM-loaded code +is given an address assigned at load time.
+Note that using the MAKSYM tool is essential for tracing back through the stack.
+