SLAA534A June 2013 – June 2020
Debuggers need to be able to view and modify the local variables of any function as its execution progresses.
DWARF3 does this by having the compiler keep track of where (in registers or on the stack) a function stores its data. The compiler encodes this information in a byte-coded language specified in Section 6.4 of the DWARF3 standard. This allows the debugger to progressively recreate a previous state by interpreting the byte-coded language. Each function activation is represented by a base address, called the Canonical Frame address (CFA), and a set of values corresponding to the contents of the machine's registers during that activation. Given the point to which the activation's execution has progressed, the debugger can figure out where all of the function's data is, and can unwind the stack to a previous state, including a previous function activation.
The DWARF3 standard suggests a very large unwinding table, with one row for each code address and one column for each register, virtual or not, including the CFA. Each cell contains unwinding instructions for that register at that point in time (code address).
Both the definition of the CFA and the set of registers comprising the state are architecture-specific.
The set of registers includes all the registers listed in Table 10-1, indexed by their DWARF register numbers from the first column.
For the CFA, the MSP430 ABI follows the convention suggested in the DWARF3 standard, defining it as the value of SP (R1) at the call site in the previous frame (that of the calling procedure).
The unwinding table may include registers that are not present on all MSP430 ISAs. Therefore a situation may arise in which the ISA executing the program has registers that are not mentioned in the call frame information. In this situation, the interpreter should behave as follows: