[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.
Regards,
Harald
More information about the En-Nut-Discussion
mailing list