avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue sta


From: Weddington, Eric
Subject: RE: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega
Date: Tue, 8 Jun 2010 20:13:14 -0600

 

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Bob Paddock
> Sent: Tuesday, June 08, 2010 1:02 PM
> To: Stu Bell
> Cc: address@hidden; address@hidden
> Subject: Re: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] 
> prologue/epilogue stack pointer manipulation not interrupt 
> safe in XMega
> 
> I'm not sure I'm looking in the correct place, but avr.c in my gcc
> build has the following code:
> 
> const char *
> output_movhi (rtx insn, rtx operands[], int *l)
> {
> ...
>              if(AVR_XMEGA)
>                {
>                  *l = 2;
>                  return (AS2 (out,__SP_L__,%A1)  CR_TAB
>                          AS2 (out,__SP_H__,%B1));
>                }
>              else
>                {
>                  *l = 5;
>                  return (AS2 (in,__tmp_reg__,__SREG__)  CR_TAB
>                          "cli"                          CR_TAB
>                          AS2 (out,__SP_H__,%B1)         CR_TAB
>                          AS2 (out,__SREG__,__tmp_reg__) CR_TAB
>                          AS2 (out,__SP_L__,%A1));
> 
> 
> This suggests that xmega code should simply be restoring the stack
> pointer.  (Note that on the xmega, when SPL is written all interrupts
> are disabled for up to four instructions or until SPH is also
> written.)  However, when I look at the disassembly of the
> __prologue_saves__ and __epilogue_restores__ code for the xmega
> libgcc.a libraries, I see the code for the non-AVR_XMEGA path.  The
> libgcc.a libraries from winavr20100110 are the same.
> ============

Thanks again for pointing this out. Those routines in libgcc are assembly 
routines, and they are not modified for xmega like they should be. The 
output_movhi routine in avr.c generates the correct code, but that is for the 
RTL code from compiled C; it doesn't cover straight assembly routines like that 
in libgcc.

I'll see about getting this fixed..... Ok. Please see attached new xmega patch. 
The new hunk is at the bottom. Any objections? Or does it look ok?

Eric

Attachment: 51-gcc-4.4.3-xmega-v14.patch
Description: 51-gcc-4.4.3-xmega-v14.patch


reply via email to

[Prev in Thread] Current Thread [Next in Thread]