Re: Request for clarification - call frame instruction DW_CFA_remember_state

[David B Anderson <davea at quasar dot engr dot sgi dot com>]

Ron Brender writes:
|>In section 6.4.2 Call Frame Instructions, Draft 5DW,
|>November 30, 2000 states:
|>
|>  Re 13. DW_CFA_remember_state
|>    The DW_CFA_remember_state instruction takes no arguments.
|>    The required action is to push the set of rules for every
|>    _register_....
|>
|>It is unclear from section 6.4.1 "Structure of Call Frame
|>Information" whether or not CFA is intended to be a register
|>for this purpose.
|
|Comment 1:
|
|The description of DW_CFA_remember_state and DW_CFA_restore_state is
|preceded by the following italics comment:
|
|    "The next two instructions provide the ability to stack and retrieve
|    compete register states. They may be useful, for example, for a
|    compiler that moves epilogue code into the body of a function."

In addition, the table beginning 6.4.1 is followed by:

"The first column indicates an address for every location that contains
code in a program.  (In shared objects, this is an object-relative
offset.)  The remaining columns contain virtual unwinding rules that are
associated with the indicated location.  The first column of the rules
defines the CFA rule which is a register and a signed offset that are
added together to compute the CFA value.

"The remaining columns are labeled by register number.  This includes
some registers that have special designation on some architectures such
as the PC and the stack pointer register.  (The actual mapping of
registers for a particular architecture is performed by the augmenter.)
The register columns contain rules that describe
whether a given register has been saved and the rule to find
the value for the register in the previous frame."

The above paragraph is, it seems to me, crystal clear. CFA is a column
in the table after LOC and therefore has a register number
(it not necessarily a physical register in a given
implentation, but it is assigned a dwarf register number).



|Would anyone object if I changed the descriptions to read
|
|  13. DW_CFA_remember_state
|
|      The DW_CFA_remember_state instruction takes no arguments. The
|      required action is to push the set of rules for the CFA together
|      with all of the registers onto an implicit stack.

|
|  14. DW_CFA_restore_state
| 
|      The DW_CFA_restore_state instruction takes no arguments. The
|      required action is to pop the set of rules (for the CFA and
|      registers) off the implicit stack and place them in the current
|      row.
|
|Does anyone care to argue differently?

Well, note my quote from 6.4.1. 
	a) the above two have different (non-parallel) wording.
	   this is not desirable: the wording should match, IMO,
	   aside from the direction.

	b) CFA and any other synthetics and all physical registers
	   have rules and they are all assigned dwarf register
	   numbers, so is the above  remember-state
	   restore-state editorial change really needed?


|Comment 2:
|
|On page 99, in the paragraph following the
|
|    LOC  CFA  R0 R1 ... RN
|    L0
|    L1
|    ...
|    LN
|
|"figure", the last sentence reads:
|
|    "The first column of the rules defines the CFA rule which is a register
|    and a signed offset that are added together to compute the CFA value.
|
|As a purely editorial matter, this sentence originates in DWARF V2 and does
|not reflect our addition of DW_CFA_def_cfa_expression (see 000330.1). I
|believe this sentence needs to be changed to
|
|    "The first column of the rules defines the CFA rule which is either
|    a register and a signed offset that are added together or a
|    DWARF expression that is evaluated to compute the CFA value."
|
|Unless I hear objection, I will make this editorial change.

Good catch.

davea@sgi.com