Smells like a compiler-toolchain problem to me. -Gedare
On Wed, Nov 26, 2014 at 11:34 AM, Hesham Moustafa <heshamelmat...@gmail.com> wrote: > Hi, > > On Tue, Nov 25, 2014 at 8:21 PM, Gedare Bloom <ged...@gwu.edu> wrote: >> >> I'm pretty sure STACK_ALIGNMENT just does the initial stack align for >> the start of the stack. The compiler is responsible for laying out the >> frames after that, and for generating aligned entries in the stack >> itself. Probably the compiler is being too lax. Check for some >> compiler flags for the target that might be used to increase the >> alignment, for example if there is a strict alignment flag. Check with >> the epiphany / parallela boards too, ask about compiler flags for >> alignment problems. >> > I checked their GCC port, and I think they define the proper macros for > stack alignments to 8 bytes. However, when debugging on real HW > (Parallella), I can see that some structures are allocated on non 8-bytes > boundaries, and also structures passed as function arguments are not > aligned. >> >> -Gedare >> >> On Tue, Nov 25, 2014 at 2:06 PM, Hesham Moustafa >> <heshamelmat...@gmail.com> wrote: >> > Hi all, >> > >> > I came across an issue with alignment when I am porting RTEMS to >> > Epiphany >> > now. The reference manual says that stores should be aligned according >> > to >> > the store instruction type (half word, word, double word). For example >> > strd >> > instruction should get an address aligned to 8 bytes. Although I set >> > CPU_ALIGNMENT and Stack aliment macros to 8 in cpu.h, I still get some >> > automatic variables not aligned to 8 bytes, which causes an exception >> > when >> > executing relevant (double) store/load instructions. >> > >> > I had to apply a brute-force solution to get over this problem. For >> > example >> > I add alignment's attribute to "CORE_mutex_Attributes attr __attribute__ >> > ((aligned (8)));" and I set "#define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC >> > TRUE" >> > instead of using CPU_TIMESTAMP_USE_INT64 >> > >> > Is there any other good solution for such a problem? >> > >> > Regards, >> > Hesham >> > >> > _______________________________________________ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel > > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
