SPRAB89A September 2011 – March 2014
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 12-1, indexed by their DWARF register numbers from the first column.
For the CFA, the C6000 ABI follows the convention suggested in the DWARF3 standard, defining it as the value of SP (B15) at the call site in the previous frame (that of the calling procedure).
There is no distinct column in the unwinding table for the virtual return address as suggested in Section 6.4.4 of the DWARF3 standard. In accordance with the calling conventions, the return address is represented by the B3 column of the unwinding table.
The unwinding table may include registers that are not present on all C6000 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: