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
- Date: Fri, 14 Jun 2002 16:15:09 -0700
- Subject: Re: [ECOS] bug allert, variable alignment problem in ecos
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