[En-Nut-Discussion] CM3 Stack alignment

Harald Kipp harald.kipp at egnite.de
Tue Sep 24 10:38:51 CEST 2013

Hi Uwe,

On 23.09.2013 18:50, bon at elektron.ikp.physik.tu-darmstadt.de wrote:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

>     Harald> You mean the start of stack memory or the current stack pointer
>     Harald> value?
> It is somehow explained by the weblink I gave and the mailinglist discussion
> about the gcc compiler, mostly Bob's findings.

Sorry, I haven't been able to follow that thread.

> In short: The start of stack memory must be 8 byte aligned. 
>     Harald> While I can imagine, that the latter may be required, I have no
>     Harald> idea how the va_arg() is influenced by the location of the
>     Harald> stack's top.
> Arm calling convention says to put 8-byte entities to R0/R1 or R2/R3. So if
> R0 is already occupied by a function argument, a second 64-byte
> argument is put to R2/R3 while skipping R1. Further function arguments are
> pushed on the stack, with 8-byte values on a 8-byte boundary, eventually
> skipping a 4-byte stack value. The va_arg magic fetches 8-byte values from
> this 8-byte boundary, eventually skipping an unused 4-byte stack.

Thanks for this detailed explanation. Now I got it.

>     Harald> Can you explain, why we need to adjust the stack's size?
> This is for security reason, so the effective stack size is not smaller than
> the calling code requested. 

Good point. (Actually I recognized this a few minutes after hitting the
send button.)

>     Harald> void foo(void) { int bar;
>     Harald>   /* Is my SP still 8-byte aligned here? */ ...more code...  }
> At least "bar" is only put in R0, so not effecting the stack at all. Bad
> example...

Well, it was meant exemplary, not considering any compiler optimization.

> And it is up to  the compiler to keep the stack happy. But the compiler
> doesn't know about our assembler commands setting the stack, so these
> commands must care for stack alignment.

That was completely new to me.



More information about the En-Nut-Discussion mailing list