Lpc2000

Marko Panger wrote:
> 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
>>
>> 
>>

Hello Marko,

do you still know where you to find these patches? I would take a look into, because I started to
search the gcc sources for the root of this problem. Maybe there is a simple patch which do not
touch sensible code in gcc. To fix something in the ARM section of GCC would be more easy, but the
fact that this occurs along with optimization makes it very tricky!

  Sten

-- 
/************************************************
 Do you need a tiny and efficient real time
 operating system (RTOS) with a preemtive
 multitasking for LPC2000 or AT91SAM7?

   http://nanortos.net-attack.de/

 Or some open-source tools and code for LPC2000?

   http://www.net-attack.de/

************************************************/