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



> -----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


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