Lpc2000

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!

Regards,

TomW



-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------