Issue 020902.1: Describing the Stack Pointer in the Call Frame Information
Keith Walker:
I believe that I have spotted and error/deficiency in the Call Frame
Information Example is DWARF3 Draft 8 Appendix D.5.
The problem is the incorrect description of the Stack Pointer (R7) in the
generated conceptual matrix.
On entry to the function, the matrix at address "foo" has the rule for R7
as "same value". This is correct.
The code then executes the instruction "sub R7, R7, <fs>"
The next entry in the matrix at address "foo+4" still has the rule for R7
as "same value". But this cannot be true as the executed instruction has
just altered the value of R7. Unfortunately there isn't a Call Frame
Instruction which allows the previous value of R7 to be correctly described.
In order for this register to be correctly described I believe that maybe
what is required is a new Call Frame Instruction similar to
DW_CFA_expression but which computes the actual value of the previous value
of the register (rather than the location of the value).
Keith.Walker
I would first like to clarify that I agree with you on how the CFA is
implemented, I just think that the way it is expressed is unclear and the
example provided incorrect.
Dave Anderson At 09:11 AM 02-09-02 -0700, you wrote:
>a) In dwarf3 sec 6.4.1, the 'register rules' are listed.
> Register values are recovered via these rules.
> None of them other than 'architectural' allow for
> registers to be recovered via calculation: they only
> allow for registers to be recovered via copying from the stack
> or from other registers.
>
>
>b) The stack pointer is special. It does not follow a)!
Surely this by definition means that it invokes the 'architectural' rule.
> In 6.4 (italics) it says:
> CFA is typically defined to be the value of the
> stack pointer in the previous frame
But as this is in italics this is not part of the specification's formal
definition.
Therefore I assume that this means that each implementation which follows
this model needs to state this in it's implementation specification.
This would therefore also state (or imply) the 'architectural' rule for
obtaining the stack pointer's value.
> In your case in hand the SP value does not change in dwarf,
> but the CFA changes by <fs>, the size of the stack pointer change.
> In other words, the 'sp' register rule (R7 in your email)
> is useless and
> unused for this with this sort of code generation.
> 'undefined value' is appropriate for the register rule once
> the register is incremented.
>
> Notice that in D.5, indeed CFA changes in the example.
So I think that we are agreed that the current example in D.5 is incorrect
in have 's' in all the rows.
I now think that the R7 column should probably have an 'a' with the
following added to the notes for Figure 56:
6. a = architectural rule
Also the description of the hypothetical RISC machine should also state:
The CFA is defined to be the value of the stack pointer in the previous
frame.
This would make it much clearer that in fact most implementations invoke
the architectural rule and need to define it for their implementation.
Proposal by David Anderson based on Keith Walker's comments.
PROPOSAL:
In Appendixd D.5 Call Frame Infomation Example
Add a new bullet item
"o The CFA value in the current frame is defined to be the
value of the stack pointer in the previous frame."
In the R7 column of figure 56:
The all lines should be 'a' in the r7 column.
Following figure 56, we should have a small table
containing some thing like
u means the register is 'undefined value', not not restorable.
s means the register is 'same value' so on restoring the previious
frame the value is correct as is.
a means the rule is architectural: on restoring the previous frame
for the hypothetical architecture, insert the value of the CFA.
c-N means the rule is take the cfa value, subtract N from it,
getting a stack address where the previous frame's value is located,
use that value-on-the-stack in restoring the previous frame.
---------------------------------------------------------------
Accepted as follows:
Replace all of the R7 values in Figure 56 with 'a' and add some
text an entry to the explanations after Figure 56. It could be
's' on the first and last instructions, it's been pointed out,
but that is a result of being architecturally defined, not by
construction.
Clarification: Jim says that in 6.4.1 the description refers to
"the table". In Figure 56 instead of "conceptual matrix" he suggests
"conceptual table" (I think he suggested), plus cross references
between 6.4.1 and Figure 56.
