From: Nick Garnett <nickg@ecoscentric.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Billy <billy@dadadada.net>,
eCos discussion <ecos-discuss@sources.redhat.com>
Subject: Re: [ECOS] variable length automatic arrays.
Date: Mon, 18 Apr 2005 13:20:00 -0000 [thread overview]
Message-ID: <m3r7h8w86p.fsf@xl5.calivar.com> (raw)
In-Reply-To: <20050417153843.GU21136@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
> On Sun, Apr 17, 2005 at 11:16:22AM -0400, Billy wrote:
> > Short question:
> >
> > Does eCos allocate dynamically sized arrays?
> >
> > Longer version:
> >
> > I'm worried about dynamic arrays under arm-elf-gcc 3.3.4.
> >
> > Looks like our application code, at least, is being adversely
> > affected by this bug:
> >
> > "gcc-3.3: Miscompiles automatic dynamic arrays"
> > http://lists.debian.org/debian-gcc/2004/07/msg00135.html
> >
> > So we're going through our app hunting these down. Upgrading
> > the compiler to 3.4 might fix it, but new parser fussiness
> > appears to be making that a more painful option than bughunting.
> >
> > Does eCos code rely on this gcc feature? Do we have
> > to audit eCos code for varlength automatic arrays
> > or just our app code?
>
> eCos should not be using this feature.
The failure referred to in the Debian list seems to be only under
specific conditions with -mpreferred-stack-boundary=2, which only
applied to x86 targets. The default value is 4, for 16 byte stack
alignment. This is also the stack alignment that eCos attempts to
maintain. So it it probably a good idea to remove that option.
On a general point, variable length auto arrays are a very bad idea in
embedded systems. It makes it very difficult to estimate stack usage,
which can result in stack overflow and memory corruption. Just say no.
--
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com The eCos and RedBoot experts
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
prev parent reply other threads:[~2005-04-18 13:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-17 15:36 Billy
2005-04-17 16:09 ` Andrew Lunn
2005-04-18 13:20 ` Nick Garnett [this message]
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=m3r7h8w86p.fsf@xl5.calivar.com \
--to=nickg@ecoscentric.com \
--cc=andrew@lunn.ch \
--cc=billy@dadadada.net \
--cc=ecos-discuss@sources.redhat.com \
/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).