[Bug c/44091] New: [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

GCC generates an invalid stack frame usage sequence in a function epilogue.

Function prologue with comments:

        .align  2
        .global rtems_bdbuf_read
        .code   16
        .thumb_func
        .type   rtems_bdbuf_read, %function
rtems_bdbuf_read:
        push    {r4, r5, r6, r7, lr}
        sub     sp, sp, #60
        add     r7, sp, #8
        /*
         * We have now reserved a stack frame in a two step process.  The
         * non-volatile register r7 will be use as an local variable anchor.
         */
        str     r3, [r7, #4]
        mov     r3, #0
        str     r3, [r7, #48]
        str     r3, [r7, #44]
        str     r3, [r7, #40]
        mov     r3, r7
        add     r3, r3, #44
        str     r3, [sp]
        sub     r3, r3, #4
        str     r3, [sp, #4]
        add     r3, r3, #8
        bl      rtems_bdbuf_obtain_disk
        str     r0, [r7, #12]
        cmp     r0, #0
        beq     .LCB3661
        b       .L520   @long jump
.LCB3661:

Function epilogue with comments:
.L520:
        mov     sp, r7
        add     sp, sp, #52
        /*
         * Here we released the second part of our stack frame which contains
         * local variables.
         */
        ldr     r0, [r7, #12]
        /*
         * Here we used the second part of our stack frame which contains local
         * variables.  We read a status variable from the stack frame that will
         * be returned now.  That means we use a part of the frame that we
         * already released.  In case an interrupt happens between these two
         * instructions (add and ldr) we may have a big problem.  These two
         * instructions are in the wrong order, the reverse order is correct.
         */
        @ sp needed for prologue
        pop     {r4, r5, r6, r7, pc}

Attached files follow.


-- 
           Summary: [ARM/Thumb] Invalid stack frame usage at -Os
           Product: gcc
           Version: 4.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sebastian dot huber at embedded-brains dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-rtems4.10


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091