On November 26, 2014 10:34:16 AM CST, 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.
So the stack is correctly aligned when the task is started but allocation of variables is misaligned? If so, that's a GCC bug. If these are malloced, then it is an issue for the heap configuration for this port. >-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
