RE: Appendix 5 problem?

[davea at quasar dot engr dot sgi dot com (David B Anderson)]

Brian Nettleton" <brian.nettleton@windriver.com> writes:
>This looks like a deeper problem to me.  I agree that the
>table in Appendix 5, which David calls "The Foo Subroutine
>Table," should have both positive offsets (R7+fsize,
>R6+fsize) and negative offsets (c-12, c-8, and c-4).
>However I don't think the standard allows for this, since
>all offsets are unsigned in the CIE and FDE entries.  The

Um. Yikes.

I'm looking at what MIPS/SGI has always produced.
Example using dwarfdump:
<  0><0:0xc8><dwarf_new_die><fde offset 0x20 length: 0x40><eh offset none>
    00000000:   cfa=00(r29/sp) ra=r31 slk=u
    00000004:   cfa=80(r29/sp) ra=r31 slk=u
    0000001c:   cfa=80(r29/sp) ra=-24(cfa) slk=u
    00000024:   cfa=80(r29/sp) r28/gp=-16(cfa) ra=-24(cfa) slk=u
    00000038:   cfa=80(r29/sp) r19/s3=-32(cfa) r28/gp=-16(cfa) ra=-24(cfa) slk=u
    00000060:   cfa=80(r29/sp) r19/s3=-32(cfa) r28/gp=-16(cfa) r31=r3/v1 ra=-24(cfa) slk=u
    00000070:   cfa=00(r29/sp) r31=r3/v1 ra=-24(cfa) slk=u
    00000078:   cfa=80(r29/sp) r19/s3=-32(cfa) r28/gp=-16(cfa) ra=-24(cfa) slk=u
    000000b4:   cfa=80(r29/sp) r19/s3=-32(cfa) r28/gp=-16(cfa) r31=r5/a1 ra=-24(cfa) slk=u
    000000c0:   cfa=00(r29/sp) r31=r5/a1 ra=-24(cfa) slk=u

data_alignment_factor is -4 (n32 ABI) or -8 (64 ABI).

What I just realized is that we(sgi) have been treating the cfa
rule as reg+unsigned and
only applying the data_alignment_factor to 
DW_CFA_offset.

The  3rd paragraph of 6.4.1 says that the cfa rule has a signed offset
while DW_CFA_def_cfa_offset and DW_CFA_def_cfa
detailed descriptions (items 15, 17) do not mention factoring the offset.
(DW_CFA_offset_extended and CW_CFA_offset, items
2 and 8 do mention factoring).

in brief:
cfa, old sp, virtual frame pointer -> higher address
              frame space for register save, locals, etc
current sp                         -> (lower address, by 80)






>standard (assuming DW_CFA_def_cfa_offset is a factored
>offset) does support changing the sign of all offsets in
>the table, but doesn't support mixed signs in the table.
>David argues for a explanatory change to the value at
>fde+17 to change <fsize>/4 to be -<fsize>/-4.
>Unfortunately if DW_CFA_def_cfa_offset is a factored
>offset, as proposed, and the factor is -4 then the
>factored offset in this case needs to be negative as well
>(to produce a positive offset in the rule) and a negative
>offset isn't allowed by the standard.  You might be able
>to patch up this particular example if
>DW_CFA_def_cfa_offset is not a factored offset, but I
>suspect you can't represent a similar example with the
>stack growing towards higher addresses (in which case the
>CFA rule would have a negative offset and the other
>registers would have a positive offset).

I can no longer recall how all this came about in MIPS/SGI
(it was all done in the early 90's) it seems we overlooked
the 6.4.1 para. 3 sentence and interpreted the
DW_CFA_def_cfa_offset and DW_CFA_def_cfa
as having unsigned offsets.

>Perhaps DW_CFA_def_cfa_offset (and DW_CFA_def_cfa) need to
>have signed LEB128 offsets?  Should we go a step further
>and make all the offsets be signed?

And our libdwarf is coded to support this 'interpretation'
in that the producer code leaves it up to the caller
to do the dividing.
And dwarfdump only multiplies by the alignment for
DW_CFA_offset (which seems wrong too: why not for
DW_CFA_offset_extended?).

Sigh.  This is very ugly.

DW_CFA_offset , we use the data alignment factor, the
	client producer does the divide.

DW_CFA_offset_extended we don't use anywhere, but
	incorrectly fail to multiply the value
	by data_alignment_factor in dwarfdump.

DW_CFA_def_cfa
DW_CFA_def_cfa_offset
	For neither do we apply data_alignment anywhere.


gdb does not read .debug_frame (it appears).

gcc uses data-alignment-factor for both
DW_CFA_offset and DW_CFA_offset_extended (I only looked at
dwarf2out.c in egcs-1.1.2 ). But not for
the DW_CFA_def_cfa or DW_CFA_def_cfa_offset.

This does not make my day.  I'm putting this note out without
thinking at all about what do *do* about all this.

davea@sgi.com