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


> >>>>> "Jifl" == Jonathan Larmour <jifl at eCosCentric dot com> writes:
> 
>     Jifl> Larice Robert wrote:
>     >>>> I know that most gcc compilers places one dimensional char
>     >>>> arrays on 4 byte boundaries. But this is not the case for
>     >>>> multidimensional char arrays (and there are some of these in
>     >>>> eCos). Unfortunately my gcc compiler does not place any char
>     >>>> arrays on 4 byte boundaries. I use the arm-elf tool chain:
> 
>     <snip>
> 
>     Jifl> With that, I can apply your patch! And thanks for looking
>     Jifl> into all this and spending the time!
> 
> Hang on. Is this really the right way to tackle the problem?
> 
> What really matters is the alignment of the stack pointer. That is
> determined by the stack base, the stack size, the number of per-thread
> variables, and whether or not stack checking is enabled. Some of these
> parameters are configurable and e.g. there is no alignment constraint
> for CYGNUM_KERNEL_THREADS_STACK_CHECK_DATA_SIZE. Simply aligning the
> stack base is not sufficient, you can still end up with a misaligned
> stack pointer.
> 
> In the synthetic target I ensure that the stack pointer is aligned to
> a 16-byte boundary in HAL_THREAD_INIT_CONTEXT(), and
> CYGNUM_HAL_STACK_SIZE_MINIMUM is large enough to compensate for the
> possible loss of 15 bytes of stack.
> 
> Let's not start adding alignment directives to every testcase and
> program without first considering alternatives.
> 
> Bart

Hello Bart,

there are not only stackspaces broken.
for example there are code sniplets which look like this
  char intr[sizeof(class Cyg_Int_something)];
and elsewhere this thing is recast to the actual class object

there are some gobal char arrays which are obviously used as
mempool for something.

the basic issue here is to learn that one can't request a char array
from any c compiler, and then to expect its suitabilty for anything else
than a char array.

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]