Re: [ECOS] Stack access violations in eCos

[Nick Garnett <nickg at ecoscentric dot com>]

Bart Veer <bartv at ecoscentric dot com> writes:

> Any change that aligns the base of the stack is insufficient. The
> stack pointer can still end up misaligned because of e.g.
> CYGNUM_KERNEL_THREADS_STACK_CHECK_DATA_SIZE. Offhand I can think of
> three ways of addressing the problem:
> 
> 1) invent a new way of defining stacks, e.g.:
> 
>        CYG_STACK(thread1_stack, 2048);
> 

...

> 
>    Introducing something like this would require changing all existing
>    stack definitions in eCos, including all the testcases.
>

Clearly a non-starter.


> 2) adjust the stack pointer during thread creation, e.g.
> 
>     register CYG_WORD* _sp_ = ((CYG_WORD*)((_sparg_) &~15));
> 
>    This could be done in certain HAL's, e.g. I already do this in
>    HAL_THREAD_INIT_CONTEXT() in the synthetic target. Or possibly it
>    could be done more centrally in the kernel's
>    Cyg_HardwareThread::attach_stack(), using an alignment #define
>    provided by the HAL. Or optionally provided by the HAL, with the
>    kernel using a #ifdef. Or possibly we have a default alignment of
>    e.g. 4.
> 
>    This would be a much smaller change than patching all the testcases
>    with CYG_STACK macros or alignment directives, and probably more
>    robust. There is a risk that some bytes of the provided stack will
>    be wasted, but if the application developer is careful then the
>    size will be just right and aligning the stack pointer has no
>    effect. There are also a couple of extra cycles to do this
>    alignment, but only during thread creation.

This is clearly the correct way of handling stack alignment. Those
architectures that require their stacks aligned should already have
the appropriate code in HAL_THREAD_INIT_CONTEXT(). Certainly i386,
MIPS and PowerPC do. Any architecture that requires alignment but does
not do it here is broken and should be fixed.

> 
> 3) ignore the problem and force application developers to provide
>    sensible stacks. That is fine in theory, but does not work well for
>    code that is supposed to be portable. e.g. the testcases.

Another non-starter I think.

> 
> Personally I favour option 2. For carefully written applications it
> involves no wasted memory, just a couple of extra cycles during thread
> creation. However other maintainers may disagree, so further comments
> are invited.

I agree entirely with Bart here. (Don't all fall of your chairs at
once :-)

> 
> Regarding other aspects of the patch, aligning arrays that will end up
> being used for structures/objects, see
> http://sources.redhat.com/ml/ecos-discuss/2003-03/msg00299.html
> In most cases it should be possible to have a much cleaner solution
> than adding alignment directives, and let the compiler do the work.
>

Agreed. Although there are some places, in the POSIX library for
example, where embedded char arrays are used to contain thread and
condition variable objects. We may need to add alignment directives to
these.


-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss