RE: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epiloguestack pointer manipulation not interrupt safe in XMega

[Weddington, Eric]

BTW, the patch that was attached to this message will NOT be the final XMEGA 
patch for the upcoming release. There are other outstanding issues (raised on 
the mailing lists recently) with the xmega support that I hope to address in 
the next day or two.

Eric Weddington

> > -----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
>