This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Stack access violations in eCos


> Nick Garnett wrote:
> > Bart wrote:
> >>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.
> 
> Looking at it, in fact virtually all architectures except SH seem to do 
> this. So I'd ask Erik and Robert Larice what architectures they were using 
> that exposed this problem for them.
> 
> One _potential_ problem is that some align the stack to say 16 byte 
> alignment *but* then go and take off some space for a saved context - 
> normally sizeof(HAL_SavedRegisters) but there are some differences in 
> different architectures. The result is something that may now only be 4 
> byte aligned, which may cause problems for those archs that need more, 
> most obviously FP doubles being 8 byte aligned.
> 
> So I'd ask Erik and Robert to get back to me on what archs this was with 
> anyway.

I'm using SH4 (SH7751).

calmrisc16 calmrisc32 seem to lack this alignment in HAL_THREAD_INIT_CONTEXT too.

I agree with Bart, fixing HAL_THREAD_INIT_CONTEXT is the best way.

One tiny issue then remains, the length of actual available space will be
nondeterministic. Somebody might sooner or later recompile some application,
get a different alignment of his char stack[], which will be corrected by
the macro, but the actual available stackspace might suddenly be smaller up
to 15 bytes. Of course one should have had enough headroom. But suddenly
getting a stack overflow, just by recompilation, might be a somewhat
unpleasant experience.
Perhaps it would thus be reasonable to add the alignment too, just for
better design practice.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]