[Dwarf-Discuss] DWARF for DSP like processors with multiple memories

[Roland McGrath]

> Actually I was looking more at the Call Frame Information than the
> DW_AT_frame_base; although that does lead me to ask how the two relate,
> since they both seem to be giving some of the same information. Does it ever
> make sense to have both?

CFI is independent of DIEs and serves to allow stack unwinding.
DW_AT_frame_base exists to optimize location expressions used in DIEs that
would otherwise be repetitive (instead they are short and use DW_OP_fbreg).

DWARF 3 has DW_OP_call_frame_cfa so that location expressions for variables
(or for DW_AT_frame_base) can refer to calculations based on the CFI
definition of the CFA rather than recapitulating the derivation of the CFA
in the form of a complex DWARF expression.

> The reason I am looking at Call Frame Information is that we want to
> describe how registers are saved on stacks during a call. Extending
> DW_AT_frame_base might help with finding variables on the stacks, but I
> think we need call frame style information to be able to do a full job of
> unwinding the stacks.

CFI is indeed what you need for unwinding.  
No DIE attributes are involved in that.

CFI yields saved register locations in a few kinds of terms:
* register number holding the value
* register number holding (biased) address of the value
* DWARF expression yielding the address of the value
* DWARF expression yielding the value
(These are the fundamentals after folding CFA-relative with CFA definitions.)

I can imagine extending your CFI engine to implicitly track "address kind"
and have that flow from the register containing an address.  i.e., if there
is a register number that is for "stack address in special memory A" then
you'd know from which register you got the address from that it was an
"A-space" address.  This approach doesn't help at all if alternate-space
addresses might be held in any register or if all addresses stored in a
given kind of memory are not all a single kind of address.

The explicit notions involving "address" in CFI have no way to distinguish
different address spaces.  There is no way to say that the CFA value itself
has an address space component.  Aside from the trivial register case, the
one not explicitly involving an address is the "expression yielding the
value" case (DW_CFA_val_expression).

In DW_CFA_val_expression, you use a DWARF expression to compute the saved
value of the caller's register, rather than the address where it's saved.
Here, you can use DW_OP_xderef{,_size}.  These expression operators are the
only explicit thing for alternate address spaces tied into CFI in any way.

The intent of DW_CFA_val_expression (and other uses of DWARF expressions
for values rather than locations) is that the expression is a black-box
machine to compute the value that will be restored, and can't be
reverse-engineered into a way to change the saved value in situ.  So that's
only half the power that most CFI most of the time gives to a debugger over
most of the registers.

If you need a lot of flexibility in combinations of different-space
addresses in code and data structures, I think you'll have to extend the
CFI spec (as well as some DIE specs like pointer types).  Or else just find
a way for address space and address to be implicitly packed into what
DWARF thinks is a "target address".


Thanks,
Roland