> 00000000 00000010 ffffffff CIE
> Version: 3
> Augmentation: ""
> Code alignment factor: 1
> Data alignment factor: -4
> Return address column: 17
>
> DW_CFA_def_cfa: r0 ofs 4
> DW_CFA_offset: r17 at cfa-4
> DW_CFA_nop
> DW_CFA_nop
OK so r0 (sp) is the CFA register upon entering the function. Then...
> 00000014 00000030 00000000 FDE cie=00000000 pc=00000000..00000043
> DW_CFA_advance_loc4: 2 to 00000002
> DW_CFA_def_cfa_offset: 32
> DW_CFA_offset: r12 at cfa-8
> DW_CFA_offset: r11 at cfa-12
> DW_CFA_offset: r10 at cfa-16
> DW_CFA_offset: r9 at cfa-20
> DW_CFA_offset: r8 at cfa-24
> DW_CFA_offset: r7 at cfa-28
> DW_CFA_offset: r6 at cfa-32
> DW_CFA_advance_loc4: 3 to 00000005
> DW_CFA_def_cfa: r6 ofs 36
... r6 (fp) briefly becomes the CFA register but...
> DW_CFA_advance_loc4: 2 to 00000007
> DW_CFA_def_cfa_register: r0
... r0 (sp) is restored almost immediately as the CFA register. That's the
bug, r6 (fp) must be kept as the CFA register throughout the function.
> Does the backend have to *not* mark further changes to the stack
> pointer in the prologue as frame related, if the function calls
> alloca?
I think that the bug is unrelated to alloca or stack checking:
_medium_frame:
pushm r6-r12
add #-4, r0, r6 ; marked frame-related (fp = sp - 4)
mov.L r6, r0 ; marked frame-related (sp = fp)
. . . ; stack checking code goes here
add #0xffffc000, r0 ; not marked frame-related
The "mov.L r6, r0" instruction must never be marked as frame-related, for any
function.
--
Eric Botcazou
