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


             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: link
Be 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).