* Re: [ECOS] bug allert, variable alignment problem in ecos
@ 2002-06-12 9:58 Stephen Morgan
2002-06-14 4:02 ` Larice Robert
0 siblings, 1 reply; 4+ messages in thread
From: Stephen Morgan @ 2002-06-12 9:58 UTC (permalink / raw)
To: Larice Robert; +Cc: ecos-discuss, ecos-discuss-owner
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] bug allert, variable alignment problem in ecos
2002-06-12 9:58 [ECOS] bug allert, variable alignment problem in ecos Stephen Morgan
@ 2002-06-14 4:02 ` Larice Robert
0 siblings, 0 replies; 4+ messages in thread
From: Larice Robert @ 2002-06-14 4:02 UTC (permalink / raw)
To: Stephen Morgan; +Cc: ecos-discuss
Hello Stephen,
how did you deal with this, did you stop the project, did you find
a solution, or did you just live with the linker lottery.
most of the time you wont notice the problem, because most global objects
are aligned to 4 byte. so if there are just few in-between, you have
a good chance to be lucky.
actually the problem i've described is not C++ specific. though
the want to allocate space for some class object, and the want
to avoid constructor calling, has led to some
char space[sizeof(class ..)];
in the ecos tree, which is another manifestation of the alignment problem.
to extend your aside, for me too, the decision to use C++ for the
bit-tiddling internals of an embedded realtime os is a bit
unexpected. but with great care can be done, and has merits too.
anyway, i've sent a patch for almost 200 dangerous global variables
to ecos-patches. (though most of them are in some test directories, and
thus of minor significance. those will even be helpfull to get
accustomed with the debugger)
Robert Larice
> 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
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] bug allert, variable alignment problem in ecos
@ 2002-06-14 16:15 Stephen Morgan
0 siblings, 0 replies; 4+ messages in thread
From: Stephen Morgan @ 2002-06-14 16:15 UTC (permalink / raw)
To: Larice Robert; +Cc: ecos-discuss
Sorry for the slow reply.
I cheated. For cases in which I found the problem -- luckily, there
weren't all that many --, I told gcc to align the C and C++ fields on a
large enough boundary that the layouts matched. For example, I changed kapidata.h to align fields in the thread data structures.
First, I added a macro that allowed me to align a field using gcc's
"attribute" capability for my platform (which I'll call "blech"):
#ifdef CYGPKG_HAL_BLECH
#define CYGPKG_HAL_ALIGNED __attribute__ ((aligned (8)))
#else // ! CYGPKG_HAL_BLECH
#define CYGPKG_HAL_ALIGNED
#endif // CYKPKG_HAL_BLECH
Then, I used the macro to align fields that weren't otherwise properly
aligned. For example, I changed CYG_THREADTIMER_MEMBERS from:
#define CYG_THREADTIMER_MEMBERS \
CYG_ALARM_MEMBERS \
cyg_thread *thread;
to:
#define CYG_THREADTIMER_MEMBERS \
CYG_ALARM_MEMBERS \
cyg_thread *thread CYGPKG_HAL_ALIGNED ;
It wasn't pretty, but it worked and we had to meet a deadline...
(BTW, I couldn't readily cut and paste from the source to this note, so I
typed in the above. It may contain errors!)
Stephen P. Morgan
Larice Robert <larice@vidisys.de>
06/14/2002 04:03 AM
To: Stephen Morgan/Almaden/IBM@IBMUS
cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] bug allert, variable alignment problem in ecos
Hello Stephen,
how did you deal with this, did you stop the project, did you find
a solution, or did you just live with the linker lottery.
most of the time you wont notice the problem, because most global
objects
are aligned to 4 byte. so if there are just few in-between, you have
a good chance to be lucky.
actually the problem i've described is not C++ specific. though
the want to allocate space for some class object, and the want
to avoid constructor calling, has led to some
char space[sizeof(class ..)];
in the ecos tree, which is another manifestation of the alignment
problem.
to extend your aside, for me too, the decision to use C++ for the
bit-tiddling internals of an embedded realtime os is a bit
unexpected. but with great care can be done, and has merits too.
anyway, i've sent a patch for almost 200 dangerous global variables
to ecos-patches. (though most of them are in some test directories, and
thus of minor significance. those will even be helpfull to get
accustomed with the debugger)
Robert Larice
> 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
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ECOS] bug allert, variable alignment problem in ecos
@ 2002-06-12 7:01 Larice Robert
0 siblings, 0 replies; 4+ messages in thread
From: Larice Robert @ 2002-06-12 7:01 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2002-06-14 23:15 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-12 9:58 [ECOS] bug allert, variable alignment problem in ecos Stephen Morgan
2002-06-14 4:02 ` Larice Robert
-- strict thread matches above, loose matches on Subject: below --
2002-06-14 16:15 Stephen Morgan
2002-06-12 7:01 Larice Robert
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).