[En-Nut-Discussion] ARM Alignment for Threads

Bob Wirka 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:

  .bss :
    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:
Hi Bob!

> 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
D-57072 Siegen

More information about the En-Nut-Discussion mailing list