{To TomW} GCC-Bug in IRQs

Started by Sten March 25, 2006
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!)

At the moment I'm using a dirty workaround by generating correct entry and exit code "manually" in a
naked function.

Thanks,
Sten

-----------------
Test-case:

#include
#include

void irqFunc2a(void) __attribute__((interrupt("IRQ")));
void dummy(void);

void irqFunc2a(void) {
dummy();
}
void dummy(void) {
int test;

test = *((volatile char*) 0xffff);
test += 10;
*((volatile char*) 0xffff) = test;
}

Compile these functions with:
$ arm-elf-gcc -mcpu=arm7tdmi-s -mthumb-interwork -fomit-frame-pointer -c test.c
OR
$ arm-elf-gcc -mcpu=arm7tdmi-s -mthumb-interwork -O2 -c test.c

and have a look at operations on LR register at entry and exit code of irqFunc2a() with:
$ arm-elf-objdump -DS test.o

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

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

Yahoo! Groups Links

An Engineer's Guide to the LPC2100 Series

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?
Regards,

TomW

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

Yahoo! Groups Links
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!)

At the moment I'm using a dirty workaround by generating correct entry and exit code "manually" in a
naked function.

Thanks,
Sten

-----------------
Test-case:

#include <stdio.h>
#include <stdlib.h>

void irqFunc2a(void) __attribute__((interrupt("IRQ")));
void dummy(void);

void irqFunc2a(void) {
dummy();
}
void dummy(void) {
int test;

test = *((volatile char*) 0xffff);
test += 10;
*((volatile char*) 0xffff) = test;
}

Compile these functions with:
$ arm-elf-gcc -mcpu=arm7tdmi-s -mthumb-interwork -fomit-frame-pointer -c test.c
OR
$ arm-elf-gcc -mcpu=arm7tdmi-s -mthumb-interwork -O2 -c test.c

and have a look at operations on LR register at entry and exit code of irqFunc2a() with:
$ arm-elf-objdump -DS test.o

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

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

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.

Maybe there is somebody out there, who knows something about a patch to fix this problem in GCC
directly.

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/

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

Yahoo! Groups Links
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?
Regards,

TomW

--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------
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..."
----------------

Yahoo! Groups Links
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..."
----------------

Yahoo! Groups Links
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.
>> I don't use:
>
> void someISR (void) __attribute__((interrupt("IRQ")));
>
> I declare as:
>
> void someISR (void) __attribute__((interrupt));
>
> Entry / exit code is fine.
>
> TomW
>

I've tried this. But entry/exit is still not correct.
Here's the result:

void uart_irqHandler0(void) __attribute__((interrupt));

00000204 :
204: e24ee004 sub lr, lr, #4 ; 0x4
208: e92d500f stmdb sp!, {r0, r1, r2, r3, ip, lr}
20c: e3a0120e mov r1, #-536870912 ; 0xe0000000
210: e2811903 add r1, r1, #49152 ; 0xc000
214: e3a00000 mov r0, #0 ; 0x0
218: ebfffffe bl d0
21c: e8bd500f ldmia sp!, {r0, r1, r2, r3, ip, lr}
220: e25ef004 subs pc, lr, #4 ; 0x4

Question:
Which gcc version do you use? Which command line parameters do use?
How do you differentiate between IRQ and FIQ (only r0..r7 need to be saved) if use
__attribute__((interrupt)) only?

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/

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

Yahoo! Groups Links
At 07:49 PM 3/25/2006 +0100, Sten wrote:
>I've tried this. But entry/exit is still not correct.
>Here's the result:
>
>void uart_irqHandler0(void) __attribute__((interrupt));
>
>00000204 :
> 204: e24ee004 sub lr, lr, #4 ; 0x4
> 208: e92d500f stmdb sp!, {r0, r1, r2, r3, ip, lr}
> 20c: e3a0120e mov r1, #-536870912 ; 0xe0000000
> 210: e2811903 add r1, r1, #49152 ; 0xc000
> 214: e3a00000 mov r0, #0 ; 0x0
> 218: ebfffffe bl d0
> 21c: e8bd500f ldmia sp!, {r0, r1, r2, r3, ip, lr}
> 220: e25ef004 subs pc, lr, #4 ; 0x4
>
>Question:
>Which gcc version do you use? Which command line parameters do use?
>How do you differentiate between IRQ and FIQ (only r0..r7 need to be
>saved) if use
>__attribute__((interrupt)) only?
Rather than go through all this hand-wringing why not just write an
assembly stub? You'd know it was correct and you'd be done already. At
most it would cost you an extra call from the stub to your C
function. Heck if it was small enough it might make sense to do the whole
thing in asm. For that matter you could steal one of my stubs.

Robert

" 'Freedom' has no meaning of itself. There are always restrictions, be
they legal, genetic, or physical. If you don't believe me, try to chew a
radio signal. " -- Kelvin Throop, III
http://www.aeolusdevelopment.com/

Yahoo! Groups Links
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/

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

Yahoo! Groups Links