On Wed, Nov 26, 2014 at 12:06 PM, Hesham Moustafa
<heshamelmat...@gmail.com> wrote:
> On Wed, Nov 26, 2014 at 4:46 PM, Joel Sherrill
> <joel.sherr...@oarcorp.com> wrote:
>>
>>
>>
>> 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.
>>
> Yes. I begin the stack at address 0x8EFFFFCC. Some issues with the
> mutex attribute before was solved with the attribute align statement.
Using align attribute is not a good long-term solution, so it is best
to resolve this problem now.
> For example the code below is not well generated
>
> static void _Thread_Create_idle_for_cpu( Per_CPU_Control *cpu )
> 27 {
> 28 int i = 0;
> 29 Objects_Name name;
> 30 Thread_Control *idle;
> 31
> ..
> 36 * The entire workspace is zeroed during its initialization. Thus, all
> 37 * fields not explicitly assigned were explicitly zeroed by
> 38 * _Workspace_Initialization.
> 39 */
> 40 idle = _Thread_Internal_allocate();
> 41
> 42 _Thread_Initialize(
> 43 &_Thread_Internal_information,
> 44 idle,
> 45 _Scheduler_Get_by_CPU( cpu ),
> 46 NULL, /* allocate the stack */
> 47 _Stack_Ensure_minimum(
> rtems_configuration_get_idle_task_stack_size() ),
> 48 CPU_IDLE_TASK_IS_FP,
> 49 PRIORITY_MAXIMUM,
> 50 true, /* preemptable */
> 51 THREAD_CPU_BUDGET_ALGORITHM_NONE,
> 52 NULL, /* no budget algorithm callout */
> 53 0, /* all interrupts enabled */
> 54 name
> 55 );
>
This is a good test case.
> &name is not multiple of 8, the problem happens with the last argument
> to _Thread_Initialize (name). It uses strd (store double) at which the
> program hangs. The store location MUST be double word aligned (which
> is not at run-time) although PARM_BOUNDARY is defined to 64 (bits) in
> epiphany.h at the GCC port
>
Since "name" is a stack variable, and the stack starts out aligned,
the problem seems to come from GCC's stack/frame handling.
>> 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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
