public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
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

      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).