Lpc2000

Hi Sten,

I was experiencing the same GCC bug as you encountered. It came out only 
with optimization enabled.

I've searched around I and discovered that there seems to be some 
patches out there but all of them are not 100% confirmed as working 
patches. I read about the patches on bugzilla. After that I decided that 
is better for me not to apply unconfirmed patches and I simply tricked 
GCC by calling the "ISR_Body()" function from my ISR. 

Like you I was also surprised that this bug has not been still fixed.

Regards,
marko


Sten wrote:

>Tom Walsh wrote:
>  
>
>>Sten wrote:
>>
>>
>>    
>>
>>>Tom Walsh wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>Sten wrote:
>>>>
>>>>
>>>>  
>>>>
>>>>
>>>>        
>>>>
>>>>>Hello Tom,
>>>>>
>>>>>some days ago I discovered a GCC bug on interrupt service routines for functions with
>>>>>__attribute__((interrupt("IRQ"))). At GCC-Bugzilla I found that this bug has still been reported in
>>>>>2005 under bug report #16634 in which you are involved in. Do you know why this bug is still
>>>>>"UNCONFIRMED"?!?
>>>>>
>>>>>The bug still persists in:
>>>>>arm-elf-gcc (GCC) 4.0.1
>>>>>arm-elf-gcc (GCC) 4.1.0
>>>>>
>>>>>Do you (or somebody else) have a gcc-patch to solve this problem? I took a look to the gcc sources
>>>>>by myself but the problem occurs in conjunction with optimization under conditions, where LR
>>>>>register is used for subroutine branches, and this could a little bit more tricky to solve it than
>>>>>just hacking the ARM section of GCC!
>>>>>
>>>>>Can somebody confirm this bug in the binary-tool-chain from www.gnuarm.com or on other GCC-based
>>>>>cross compiler versions? It seems gnuarm don't have any special patches against this problem, too.
>>>>>(See test-case below!)
>>>>>
>>>>>
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>>I am not sure what your question is. Why do you feel you have to 
>>>>intentionally suppress the apcs stack frame?
>>>>
>>>>  
>>>>
>>>>        
>>>>
>>>With -mapcs-frame the code produced looks good but due to the APCS a lot of overhead at entry and
>>>exit of my functions is generated. Without that option (or with -mno-apcs-frame) gcc generates wrong
>>>entry/exit code but the code footprint is more slim.
>>>In my opinion an arm-elf-gcc should produce correct code for ARM cores in any case.
>>>
>>>GCC manual says for ARM option -mapcs-frame:
>>>"Generate a stack frame that is compliant with the ARM Procedure Call Standard for all functions,
>>>even if this is not strictly necessary for correct execution of the code."
>>>
>>>My question was if you know something about the detailed status of bug report #16634? I'm wondering
>>>why it is still UNCONFIRMED since 2005.
>>>
>>>
>>>
>>>      
>>>
>>No, I don't.  AFAIK, the apcs frame is used for backtracing code.  So 
>>far, the Insight debugger has been fine for backtracing with the options 
>>I specify for compiles:
>>
>>arm-elf-gcc -c -O0 -mthumb  -mcpu=arm7tdmi -march=armv4t 
>>-DTOPLEVEL=/home/tom/MuxPad3Devel/EvntCPU/../ -I. -gstabs -DROM_RUN 
>>-I/home/tom/MuxPad3Devel/EvntCPU/../include 
>>-I/home/tom/MuxPad3Devel/EvntCPU/../libs/include -Wall 
>>-Wstrict-prototypes -Wcast-align -Wcast-qual -Wimplicit 
>>-Wmissing-declarations -Wmissing-prototypes -Wnested-externs 
>>-Wpointer-arith -Wswitch -Wredundant-decls -Wreturn-type -Wshadow 
>>-Wstrict-prototypes -Wunused -Wa,-adhlns=main2138.lst  -std=gnu99 
>>-nostdlib -nodefaultlibs 
>>-L/home/tom/devtools/armThumb-4.0.2/arm-elf/lib/thumb/interwork/ 
>>-L/home/tom/devtools/armThumb-4.0.2/lib/gcc/arm-elf/4.0.2/interwork/ -MD 
>>-MP -MF .dep/main2138.o.d -DLPC2138 
>>-I/home/tom/MuxPad3Devel/EvntCPU//include  -DLPC2138 main2138.c -o 
>>main2138.o
>>
>>I am not optimizing as yet for two reasons:
>>
>>1. I have adequate codespace, yet.
>>2. It is a nightmare to debug optimized code!
>>
>>    
>>
>
>Ok, that's the reason! I explored that it happens only in conjunction with optimization options. It
>seems that gcc is mixing up optimized code with non-optimized.
>
>Sometimes gcc results in very neat optimized code like this:
>irq:
>	sub	lr, lr, #4
>	stmdb	sp!, {r1,r2,lr}
>	...
>	ldmia	sp!, {r1,r2,pc}		@ loading pc with lr-4 directly from stack
>
>or in the default code recommended in ARM manual:
>
>irq:
>	stmdb	sp!, {r1,r2,lr}
>	...
>	ldmia	sp!, {r1,r2,lr}
>	subs	pc, lr, #4
>
>The erronous output when optimizing looks like a mixture of both:
>
>irq:
>	sub	lr, lr, #4
>	stmdb	sp!, {r1,r2,lr}
>	...
>	ldmia	sp!, {r1,r2,lr}
>	subs	sp, lr, #4
>
>Has nobody else recognized this?!?
>
>Regards.
>   Sten
>
>  
>



[Non-text portions of this message have been removed]