public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rob dot thornburrow at adder dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/44888] New: Stack pointer corruption within interrupt routine when compiled with -Os Date: Fri, 09 Jul 2010 14:11:00 -0000 [thread overview] Message-ID: <bug-44888-19422@http.gcc.gnu.org/bugzilla/> (raw) # 1 "irq.c" # 1 "<built-in>" # 1 "<command-line>" # 1 "irq.c" extern void add_irq(int, void (*irq)(void)); extern void do_something(void); static __attribute__ ((interrupt("IRQ"))) void irq(void) { unsigned long ints; ints = (*(volatile unsigned long *)(0x00000000)); ints &= ~(*(volatile unsigned long *)(0x00000004)); if (ints & 0x1) do_something(); (*(volatile unsigned long *)(0x00000000)) = ints; } void init(void) { add_irq(0, irq); } When compiled with -Os using gcc 4.5.0 (arm-none-eabi), the generated assembly for irq() subtracts 4 from the stack pointer immediately prior to calling do_something() but never adds 4 back before the function exits. This results in the program counter (and all registers saved at the start of the function) being loaded with incorrect values. This doesn't happen with 4.5.0 when compiled with no optimisation (-O0) or with 4.4.2 (arm-elf) with any optimisation level. It appears to only be a problem when the function is defined as an interrupt handler as when defined as a normal function (with standard entry/exit wrappers) the generated assembly looks correct. Target: arm-none-eabi Configured with: ../gcc-4.5.0/configure --target=arm-none-eabi --prefix=/home/ya garto/install --disable-nls --disable-shared --disable-threads --with-gcc --with -gnu-ld --with-gnu-as --with-dwarf2 --enable-languages=c,c++ --enable-interwork --enable-multilib --with-newlib --with-headers=../newlib-1.18.0/newlib/libc/incl ude --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --disable-libg omp -v Thread model: single gcc version 4.5.0 (GCC) COLLECT_GCC_OPTIONS='-mcpu=arm7tdmi-s' '-std=gnu99' '-Wall' '-c' '-fno-common' '-Os' '-o' -- Summary: Stack pointer corruption within interrupt routine when compiled with -Os Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob dot thornburrow at adder dot com GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44888
next reply other threads:[~2010-07-09 14:11 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-07-09 14:11 rob dot thornburrow at adder dot com [this message] 2010-07-12 9:35 ` [Bug target/44888] " ramana at gcc dot gnu dot org 2010-07-12 9:57 ` jiez at gcc dot gnu dot org 2010-07-12 14:07 ` jiez at gcc dot gnu dot org 2010-07-12 14:07 ` jiez at gcc dot gnu dot org 2010-07-13 8:25 ` rob dot thornburrow at adder dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-44888-19422@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).