[En-Nut-Discussion] ARM Alignment for Threads
bobwirka at yahoo.com
Fri Oct 11 05:42:04 CEST 2013
I'm working with the AT91SAM7X512.
I must be losing my mind, but I just updated to r5395, and /nut/arch/arm/ldscripts/at91sam7x512_rom.ld shows:
PROVIDE (__bss_start = .);
. = ALIGN(4);
PROVIDE (__bss_end = .);
. += 0x400;
PROVIDE (__exp_stack = .);
. += 0x400;
PROVIDE (__stack = .);
PROVIDE (__heap_start = .);
} > ram
With a 4 byte alignment ?
On Thursday, October 10, 2013 5:28 PM, Ole Reinhardt <ole.reinhardt at embedded-it.de> wrote:
> It seems that setting the alignment to 8 in the load script is not
> the solution to getting 8 byte stack alignment. Thread stacks can end
> up on a 4 byte boundary, thus screwing up va_arg().
Which platform are you working on? I reviewed Cortex context.c, and
there Uwe already implemented 8 byte alignment in rev. r5341, for AT91 I
have implemented it in rev. 5395.
> When a thread is started, it's stack is set via NutHeapAlloc(). There
> are two problems: 1) NUTMEM_ALIGNMENT defaults to 4, and 2) the
> pointer returned is set to the address of HEAPNODE->hn_next, which is
> at a 4 byte offset from the address of the heap node allocated.
I took over Uwes implementation from Cortex to AT91. There the allocated
memory is aligned _after_ allocation. In worst case 8 byes more than
requested will be allocated.
> So, even if you set NUTMEM_ALIGNMENT to 8, you still can get a stack
> pointer on a 4 byte boundary.
I took a short look to NutHeapAlloc(). Looks like NUTMEM_ALIGNMENT isn't
taken into account at all, beside of reserving anough extra bytes for
@Harald: Could you look to the code please as well? Looks like the idea
was to allow alignment, but finally it's not implemented? Have
I overseen anything?
kernel concepts GmbH Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Mob: +49-177-7420433
More information about the En-Nut-Discussion