This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: bug allert, variable alignment problem in ecos
- From: "Stephen Morgan" <smorgan at almaden dot ibm dot com>
- To: Larice Robert <larice at vidisys dot de>
- Cc: ecos-discuss at sources dot redhat dot com, ecos-discuss-owner at sources dot redhat dot com
- Date: Wed, 12 Jun 2002 09:58:32 -0700
- Subject: Re: [ECOS] bug allert, variable alignment problem in ecos
Yes. We saw the problem in debugging eCos on a MIPS32 processor and it
drove us crazy. It showed up especially in threads structures as these
are shared between C and C++ code, which apparently have different
alignment rules.
As an aside, I'm a dyed in the wool C programmer, and find C++ a miserable
language. Why would anyone mix C and C++ within an operating system? Of
course, I use vi as I find emacs incomprehensible, which may indicate
something about my sensibilities -- or merely my abilities... 8-)
Stephen P. Morgan
Larice Robert <larice@vidisys.de>
Sent by: ecos-discuss-owner@sources.redhat.com
06/12/2002 07:03 AM
To: ecos-discuss@sources.redhat.com
cc:
Subject: [ECOS] bug allert, variable alignment problem in ecos
Hello,
some time ago, i've reported a CPU access alignment problem caused by
static char idle_thread_stack[][]
in
packages/kernel/current/src/common/thread.cxx
(see http://sources.redhat.com/ml/ecos-discuss/2002-05/msg00333.html)
i've spend some time to track this down further.
the following testfile.C was compiled with several different gcc's
static char idle_thread_stack[1][2048];
static char another_try[2048];
void *preseve1 = idle_thread_stack;
void *preseve2 = another_try;
compilation is done with:
gcc -c -S -o - testfile.C
so you get the intermediate assembler output on stdout.
the two dimensional array idle_thread_stack is compiled for
1 byte alignment
by the following gcc's:
egcs-2.91.66 arm-unknown-coff-gcc, h8300-unknown-hms-gcc
gcc-2.95.2 i960-intel-coff-gcc
gcc-2.95.3 sh-elf-gcc, arm-elf-gcc, m32r-elf-gcc
gcc-3.0.4 sh-elf-gcc
most do so with the following asm line
.comm _idle_thread_stack,2048,1
(third parameter is the alignment)
the one dimensional array another_try is compiled for
4 byte alignment
by most of them, but for
1 byte alignment
by the following gcc:
gcc-2.95.3 arm-elf-gcc
a grep search through the sources of ecos reveals numerous instances
of one and two dimensional char arrays. lots of them are used for
cyg_thread_create()
to provide stack space. this function DOES NOT align the provided
space to word boundaries. thus there is real danger.
but there are non stack related problems too.
for example in sched.cxx:
CYG_BYTE cyg_sched_cpu_interrupt
[CYGNUM_KERNEL_CPU_MAX][sizeof(Cyg_Interrupt)]
CYGBLD_ANNOTATE_VARIABLE_SCHED;
which suffers the same problem.
there is even a notion in ecos/packages/kernel/current/ChangeLog
* tests/testaux.hxx:
thread_obj[][] and stack[][] are now 8-byte aligned like
certain
processors require; Cyg_Thread contains cyg_tick_count
which is
64-bit so any "standalone" C++ object would be so
aligned. These
dynamically allocated ones should be too.
in test/testaux.hxx the following is used instead of the popular
static char []:
static CYG_ALIGNMENT_TYPE thread_obj[NTHREADS] [
(sizeof(Cyg_Thread)+sizeof(CYG_ALIGNMENT_TYPE)-1)
/ sizeof(CYG_ALIGNMENT_TYPE) ];
static CYG_ALIGNMENT_TYPE stack[NTHREADS] [
(STACKSIZE+sizeof(CYG_ALIGNMENT_TYPE)-1)
/ sizeof(CYG_ALIGNMENT_TYPE) ];
any comments ?
Robert Larice
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss