Bug 11222 - arm/thumb __Unwind_SjLj_Register prologue optimization causes crash on interrupts
Summary: arm/thumb __Unwind_SjLj_Register prologue optimization causes crash on interr...
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.3
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-06-17 15:08 UTC by Leonardo Mesquita
Modified: 2015-01-16 09:14 UTC (History)
4 users (show)

See Also:
Host: i686-pc-cygwin
Target: arm-elf
Build: i686-pc-cygwin
Known to work:
Known to fail:
Last reconfirmed: 2003-07-12 01:43:01


Attachments
Preprocessor file (2.76 KB, application/x-gzip)
2003-07-12 01:34 UTC, Leonardo Mesquita
Details
This fixes a very similar bug in 4.1.1 (903 bytes, patch)
2007-08-08 05:15 UTC, Stephen Blackheath
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Leonardo Mesquita 2003-06-17 15:08:33 UTC
The generated code for thumb instruction set with -O2 optimization, when using
exceptions, has the "sub sp" instruction (ergo the allocation of local
variables) called after data manipulation on the local vars in the stack
unwinding prologue, which causes data to be corrupted on the event of an
interruption.
NOTE: it was so in Ecos, because it switches the processor mode back to
supervisor, causing the same stack pointer to be used both in the running thread
and the interrupt handler.
Comment 1 Dara Hazeghi 2003-06-18 06:17:57 UTC
Hello,

for bugs of this sort, we usually require a testcase (see http://gcc.gnu.org/bugs.html). Would you 
mind attaching one to this report. Also, gcc 3.3 just came out (and 3.2.X is no longer being 
updated), so if you could confirm whether the problem is still present with 3.3, that'd be great.

Dara
Comment 2 Leonardo Mesquita 2003-07-12 01:34:01 UTC
Created attachment 4391 [details]
Preprocessor file

Preprocessor file that causes the bug under gcc-3.3
Comment 3 Leonardo Mesquita 2003-07-12 01:35:58 UTC
I've just verified that the bug is still in gcc-3.3
The comand line I used to compile was:
arm-elf-gcc -S -mthumb teste.cpp -o teste.S -fexceptions -O2 -v -save-temps
Comment 4 Andrew Pinski 2003-07-12 01:38:13 UTC
Submitter had confirmed that 3.3 does not work.
Comment 5 Leonardo Mesquita 2003-07-12 01:38:56 UTC
gcc -v output:

Reading specs from /usr/local/arm/lib/gcc-lib/arm-elf/3.3/specs
Configured with: ../../gcc-3.3/configure --target=arm-elf --prefix=/usr/local/ar
m --disable-nls --enable-languages=c,c++ --with-newlib --with-headers=../../newl
ib-1.11.0/newlib/libc/include/ --enable-interwork
Thread model: single
gcc version 3.3
Comment 6 Andrew Pinski 2003-07-12 01:43:01 UTC
No reason why this should be in waiting any more as you already confirmed it.
One more thing build would be i686-pc-cygwin, not the options.

The options passed to gcc: -O2 -fexceptions -mthumb
Comment 7 Leonardo Mesquita 2003-07-12 01:48:12 UTC
Subject: Re:  arm/thumb __Unwind_SjLj_Register prologue
 optimization causes crash on interrupts


    Thanks.
    I didn't know what to put in that field. The description of "How to 
submit a bug" was excellent, but it had NOTHING to do with the bug 
reporting form. Maybe someone should review that document...

    Leonardo Mesquita

pinskia at physics dot uc dot edu wrote:

>PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
>
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11222
>
>
>pinskia at physics dot uc dot edu changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>             Status|WAITING                     |NEW
>     Ever Confirmed|                            |1
>  GCC build triplet|-O2 -fexceptions -mthumb    |i686-pc-cygwin
>   GCC host triplet|i686-pc-cygwin              |i686-pc-cygwini686-pc-cygwin
>   Last reconfirmed|0000-00-00 00:00:00         |2003-07-12 01:43:01
>               date|                            |
>
>
>------- Additional Comments From pinskia at physics dot uc dot edu  2003-07-12 01:43 -------
>No reason why this should be in waiting any more as you already confirmed it.
>One more thing build would be i686-pc-cygwin, not the options.
>
>The options passed to gcc: -O2 -fexceptions -mthumb
>
>
>
>------- You are receiving this mail because: -------
>You reported the bug, or are watching the reporter.
>
>
>  
>


Comment 8 Leonardo Mesquita 2003-07-12 02:04:10 UTC
I know I shouldn't submit the assembler code, but this is just the part where
the bug is, I think it might help illustrate it.

_ZN1AC1Ei: // Constructor for class "A"
    push    {r4, r5, r6, r7, lr}
    (...) // Ommited part, just pushing registers to the stack
    mov r2, #48
    mov r3, #52
    mov r7, sp       // here, r7 points to the top of the stack
    neg r2, r2
    neg r3, r3
    str r1, [r3, r7] // Oops, messing with the area before the top of the stack 
                     // (the local vars)

    str r0, [r2, r7] // Again
    ldr r3, .L28
    mov r2, #20
    neg r2, r2
    str r3, [r2, r7] // And again
    ldr r3, .L28+4
    mov r2, #16
    neg r2, r2
    str r3, [r2, r7] // Yet again
    mov r3, #12
    neg r3, r3
    str r7, [r3, r7] // Geez, won't you stop it?
    mov r2, #8
    ldr r3, .L28+8
    sub sp, sp, #60  // Finally decrements the stack pointer...
(...)
Comment 9 Stephen Blackheath 2007-08-08 05:15:01 UTC
Created attachment 14042 [details]
This fixes a very similar bug in 4.1.1

gcc version 4.1.1 contains a very similar (but not quite the same) bug where function epilogues like this are generated for ARM thumb targets.

empty:
        push    {r7, lr}
        add     r7, sp, #8
        mov     sp, r7
        sub     sp, sp, #8
        @ sp needed for prologue
        pop     {r7}
        pop     {r0}
        bx      r0

The problem is that between "mov sp, r7" and "sub sp, #8", the stack pointer points above the valid stack bottom, and if an interrupt occurs between these points, stack contents get overwritten.

To generate the above code, use this test.c file:

--- test.c
void empty(void);
void empty()
{
}
--- end test.c

Use this command:

/opt/arm-none-eabi/bin/arm-none-eabi-gcc -S -o test.s test.c -mthumb -fno-omit-frame-pointer -O2

The attached patch fixes this bug.
Comment 10 Ramana Radhakrishnan 2009-03-17 00:11:44 UTC
This should be a target bug. Also with mainline the testcase empty described in comment #9 appears fixed.

Comment 11 Ramana Radhakrishnan 2015-01-16 09:14:43 UTC
This is almost gone now. I can't reproduce it with trunk probably because arm-elf is now dead and long gone, as everything is now EABI centric.