Lpc2000

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

-- 
/************************************************
 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/

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