This is the mail archive of the
ecos-patches@sources.redhat.com
mailing list for the eCos project.
Re: Wrong declaration of idle_thread_stack
- From: Andrew Lunn <andrew at lunn dot ch>
- To: Uwe Kindler <ukindler at htwm dot de>
- Cc: ecos-patches at sources dot redhat dot com
- Date: Wed, 21 Jan 2004 19:25:48 +0100
- Subject: Re: Wrong declaration of idle_thread_stack
- References: <002701c3e030$81cec690$2c79378d@uwepc>
On Wed, Jan 21, 2004 at 04:09:01PM +0100, Uwe Kindler wrote:
> Hello,
>
> if stack checking is enabled (CYGFUN_KERNEL_THREADS_STACK_CHECKING ) then
> Cyg_HardwareThread::attach_stack expects a CYG_WORD aligned stack - at least
> the following assertions will be executed:
>
> CYG_ASSERT( NULL != base, "stack base non-NULL" );
> CYG_ASSERT( 0 == ((sizeof(CYG_WORD)-1) & (cyg_uint32)base), "stack base
> alignment" );
> CYG_ASSERT( 0 == ((sizeof(CYG_WORD)-1) & (cyg_uint32)top), "stack top
> alignment" );
>
> As far as I understand the code above, the assertions expect a CYG_WORD
> alignet stack top and stack base. The idle_thread_stack is declared as
> static char at the moment. So this is my question: What will happen if the
> idle_thread_stack is aligned to an odd address? In my opinion the assertions
> will fail (and they already did).
I was hoping some of the others how know more about gcc would comment
on this. O well, here is my 2p worth.
For all the targets which i know of, this is never an issue. The
compiler always aligns char arrays on word boundaries. So this
assertion never goes off. If this were not true, all the targets in
eCosCentrics test farm would be failing this test at regular
intervals. Same goes for the old RedHat test farm. So i guess that
something around 70 targets don't have this problem.
Now, is this really a compiler issue? I think it probably is. I
suspect there is lots of code out there in general that assumes a char
array starts on a word boundary. We could apply your patch, but i
suspect you will run into trouble some where else. I think maybe you
should be looking at the compiler. Others may however disagree.
Andrew