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.
>
>  
>
I don't use:

void someISR (void) __attribute__((interrupt("IRQ")));

I declare as:

void someISR (void) __attribute__((interrupt));

Entry / exit code is fine.



TomW



>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.
>
>Maybe there is somebody out there, who knows something about a patch to fix this problem in GCC
>directly.
>
>Regards,
>  Sten
>
>  
>


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