Hello Bob, 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) HTH Anitha >-----Original Message----- >From: avr-libc-dev-bounces+anitha.boyapati=atmel....@nongnu.org >[mailto:avr-libc-dev-bounces+anitha.boyapati=atmel....@nongnu.org] On >Behalf Of Bob Paddock >Sent: Thursday, February 10, 2011 10:52 PM >To: avr-libc-...@nongnu.org >Subject: Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack >pointermanipulation not interrupt safe in XMega > >http://savannah.nongnu.org/bugs/?29774 > >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. >http://www.nongnu.org/avr-libc/bugs.html > > >On Tue, May 4, 2010 at 12:05 PM, Matthew Vernon <invalid.nore...@gnu.org> >wrote: >> >> URL: >> <http://savannah.nongnu.org/bugs/?29774> >> >> 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 >> >> _______________________________________________________ >> >> Details: >> >> The function prologue and epilogue code (in list files __prologue_saves__ >and >> __epilogue_restores__) finish by clearing interrupts, changing the stack >> pointer, then restoring the status register (potentially enabling >> interrupts). >> >> The actual code from the list file for my XMega project is shown below. >Note >> that 0x3F is the status register (including interrupt enable), and 0x3D >with >> 0x3E are the stack pointer. >> >> The status register is preserved, then interrupts are cleared. Half of >the >> stack is written, the status register is restored, then the other half of >the >> stack is written. On most architectures this is correct as one >instruction can >> safely execute after enabling interrupts (restore SREG) before an >interrupt >> 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 >to an >> arbitrary memory location. In my application this results in stack >corruption >> 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 >the avr-libc >> project I am not sure how to implement the fix beyond my own version of >the >> library. >> >> This behavior can be tested by setting an interrupt to be always active >such >> as a very fast timer interrupt. The code will execute one instruction >between >> interrupts and therefore an interrupt will occur at the point indicated >> above. >> >> >> >> >> >> >> _______________________________________________________ >> >> Reply to this item at: >> >> <http://savannah.nongnu.org/bugs/?29774> >> >> _______________________________________________ >> Message sent via/by Savannah >> http://savannah.nongnu.org/ >> >> >> >> _______________________________________________ >> AVR-libc-dev mailing list >> avr-libc-...@nongnu.org >> http://lists.nongnu.org/mailman/listinfo/avr-libc-dev >> > >_______________________________________________ >AVR-libc-dev mailing list >avr-libc-...@nongnu.org >http://lists.nongnu.org/mailman/listinfo/avr-libc-dev _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list