[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-gcc-list] RE: [avr-libc-dev] [bug #29774] prologue/epilogue stack p
[avr-gcc-list] RE: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointermanipulation not interrupt safe in XMega
Sat, 12 Feb 2011 03:25:33 +0800
This is quite an interesting bug!! (Sorry to say that, but it is) Took me
sometime to understand all the previous conversations.
Firstly, I don't think an avr-gcc bug is filed on this... If you happen to know
the avr-gcc bug number, please let me know.
Secondly, can you the gcc version you are using? If you have not moved onto
latest release of AVR Toolchain 3.1.0, I suggest you try it and let us know.
(even AVR Toolchain 3.0.0 can be used)
As per my understanding, if the issue is just limited to __prologues_saves__
and __epilogue_restores__, then they appeared to be fixed. However I have to
verify in other places of gcc (wherever Xmega instructions involving stack
pointers are emitted)
>Behalf Of Bob Paddock
>Sent: Thursday, February 10, 2011 10:52 PM
>Subject: Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack
>pointermanipulation not interrupt safe in XMega
>Was this issue ever resolved in GCC, being an invalid bug for AVR-LibC?
>There was discussion of it back in June, and Eric had a patch, but I
>could not pick it out of the GCC Bug list.
>On Tue, May 4, 2010 at 12:05 PM, Matthew Vernon <address@hidden>
>> Summary: prologue/epilogue stack pointer manipulation not
>> interrupt safe in XMega
>> Project: AVR C Runtime Library
>> Submitted by: sunergos
>> Submitted on: Tue 04 May 2010 04:05:21 PM GMT
>> Category: Library
>> Severity: 3 - Normal
>> Priority: 5 - Normal
>> Item Group: Unknown
>> Status: None
>> Percent Complete: 0%
>> Assigned to: None
>> Open/Closed: Open
>> Discussion Lock: Any
>> Release: 1.6.8
>> Fixed Release: None
>> The function prologue and epilogue code (in list files __prologue_saves__
>> __epilogue_restores__) finish by clearing interrupts, changing the stack
>> pointer, then restoring the status register (potentially enabling
>> The actual code from the list file for my XMega project is shown below.
>> that 0x3F is the status register (including interrupt enable), and 0x3D
>> 0x3E are the stack pointer.
>> The status register is preserved, then interrupts are cleared. Half of
>> stack is written, the status register is restored, then the other half of
>> stack is written. On most architectures this is correct as one
>> safely execute after enabling interrupts (restore SREG) before an
>> can occur.
>> 0001b082 <__epilogue_restores__>:
>> 1b0aa: 0f b6 in r0, 0x3f ; 63
>> 1b0ac: f8 94 cli
>> 1b0ae: de bf out 0x3e, r29 ; 62
>> 1b0b0: 0f be out 0x3f, r0 ; 63
>> 1b0b2: cd bf out 0x3d, r28 ; 61
>> 1b0b4: ed 01 movw r28, r26
>> 1b0b6: 08 95 ret
>> The XMega, however, can jump to an interrupt immediately after the status
>> register is restored and before the second half of the stack is written.
>> Therefore any interrupt code that uses the stack will potentially write
>> arbitrary memory location. In my application this results in stack
>> and a function return to an arbitrary address.
>> The solution is to restore the status register on line later ("out
> 0x3f, r0"
>> after "out 0x3d, r28"). Since this code appears to be external to
>> project I am not sure how to implement the fix beyond my own version of
>> This behavior can be tested by setting an interrupt to be always active
>> as a very fast timer interrupt. The code will execute one instruction
>> interrupts and therefore an interrupt will occur at the point indicated
>> Reply to this item at:
>> Message sent via/by Savannah
>> AVR-libc-dev mailing list
>AVR-libc-dev mailing list
- [avr-gcc-list] RE: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointermanipulation not interrupt safe in XMega,
Boyapati, Anitha <=