PROPOSAL: add wording to frame discussion


MOTIVATION:

Tom Pennello pointed out that if one wants to recover
a register value into hardware register 'M' (stack pointer
in his email) the existing frame discussion gives applicable rules
that are not sufficient for some reasonable code generation
strategies.

In particular, if the previous frame stack pointer value
is not on the stack and not in a register and is not the CFA itself,
but has a value of CFA_value +V there is no way to represent it.

There are many other 'general expressions' that might
be needed to calculate any register value.
Such are not defined nor proposed here.


EXISTING RULES:

Say this is in column C:

same value:     C is itself
unknown:        C's value is unknown
REG R:          The value of Reg C is in register R.
offset(N):      Given offset N, add N to CFA rule offset
                The value of the register C is on the stack
                at the value of the CFA + N.

Note that in no case does this frame description actually
*look on the stack*. It simply provides information to the
consumer so the consumer can do so.

There is no way for a consumer to know that 'in the case
of a certain register or registers, the value is
the R (reg content) or offset(N) value, not a value on the stack'.


PROPOSAL GOAL:

Provide a way for producers to specify that
'rule R2 is a value, not to be interpreted as a stack offset'.

This proposal is that we not provide anything new in dwarf2,
but instead that we point out how the implementation
for a particular architecture solve this.

PROPOSED TEXT CHANGE:

The following paragraphs are all to be in italics, in a paragraph
close to the definition of the 'architectural' rule.

"One use for an 'architectural' rule may be (for some architectures)
in the recovery of the previous frame stack pointer. The producer might
define that for some columns C, an implementation-specific 'regvalue(n)' rule
is calculated just like the offset(N) rule (and using CFA as already defined)
but is interpreted by a consumer as meaning the recovered register is the
calculated value (CFA + offset N) (whereas offset(N) says the value is on
the stack at (CFA + offset N)).   In other words, this is just like offset(N)
but the consumer interprets it differently: using the value, not looking on
the run-time stack for the value."

"Another architectural rule might be that for some architectures, the CFA
itself (some register plus offset) is the value of the previous frame
stack-pointer."


ALTERNATIVES CONSIDERED AND REJECTED (not part of this proposal):

Providing some general 'dwarf expression' is possible but overly complicated.
And references to .debug_info (as in DW_OP_call* are not really wanted
here (IMO).

Adding a real 'new rule' could be painful for consumers, since the existing
rule is only implicit in the debug_frame info based on use of CFA in a given
rule.

The alternative of adding a CFAR column (like CFA, but interpreted as
(CFAR + offset N), not (value on stack at CFA + offset N)) is painful because
all of the opcodes naming CFA.

Adopted as an editorial change.