[Top][All Lists]
[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: |
Georg Lay |
Subject: |
Re: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega |
Date: |
Thu, 10 Jun 2010 16:31:40 +0200 |
User-agent: |
Thunderbird 2.0.0.19 (X11/20081227) |
Weddington, Eric schrieb:
>
>
>> -----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
To what SVN version can this patch be applied?
As far as I see the SP handling in movhi_sp_r_irq_off, movhi_sp_r_irq_on
is not changed. These insns get emitted in function prologue for SIGNAL
resp. INTERRUPT.
- [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega, Galen Seitz, 2010/06/07
- Re: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega, Georg Lay, 2010/06/08
- Re: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega, Bob Paddock, 2010/06/08
- RE: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega, Stu Bell, 2010/06/08
- Re: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega, Bob Paddock, 2010/06/08
- RE: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega, Weddington, Eric, 2010/06/08
- RE: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epiloguestack pointer manipulation not interrupt safe in XMega, Weddington, Eric, 2010/06/09
- Re: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega,
Georg Lay <=
- RE: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega, Weddington, Eric, 2010/06/10
- Re: [avr-gcc-list] Re: [avr-libc-dev] [bug #29774] prologue/epilogue stack pointer manipulation not interrupt safe in XMega, Matthew, 2010/06/09