This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Stack access violations in eCos
- From: Erik Aagaard Knudsen <EAK at penell dot com>
- To: 'Jonathan Larmour' <jifl at eCosCentric dot com>, Nick Garnett <nickg at ecoscentric dot com>
- Cc: Bart Veer <bartv at ecoscentric dot com>, ecos-discuss at sources dot redhat dot com, larice <larice at vidisys dot de>
- Date: Thu, 3 Apr 2003 09:58:08 +0200
- Subject: RE: [ECOS] Stack access violations in eCos
> -----Original Message-----
> From: Jonathan Larmour [SMTP:jifl at eCosCentric dot com]
> Sent: 2. april 2003 22:56
> To: Nick Garnett
> Cc: Bart Veer; Erik Aagaard Knudsen; ecos-discuss at sources dot redhat dot com;
> larice
> Subject: Re: [ECOS] 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.
[Erik Aagaard Knudsen]
The architecture we use is arm. I have checked
HAL_THREAD_INIT_CONTEXT and it aligns the stack on a 16 byte boundary for
this architecture. Even after corrected for HAL_SavedRegisters it is still
aligned on a 16 byte boundary. Now in fact I have only seen the problem with
POSIX threads, which is what we use the most. So I checked the code for
pthread_create. And I guess this is where our problem has its roots.
pthread_create uses the stack (without any kind of alignment) for a
structure pthread_info, which requires that the stack is aligned.
> Jifl
> --
> eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
> --[ "You can complain because roses have thorns, or you ]--
> --[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss