avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AW: [avr-gcc-list] stack layout


From: Haase Bjoern (PT-BEU/EMT) *
Subject: AW: [avr-gcc-list] stack layout
Date: Fri, 24 Jun 2005 09:41:33 +0200

Joerg Wunsch wrote

>No, you cannot perform overlap checks for the stack anyway, at not
>least useful ones.  The stack grows dynamically, so it's always the
>programmer that needs to ensure it doesn't collide with anything else.
>The compiler (or linker) has no notion of the size of the stack.  The
>default setup is similar to the (historical) Unix model where stack
>and heap are allowed to use the entire available RAM, growing towards
>from different ends.  That's the best you could get anyways, and if
>you as the programmer are changing that model, it's your
>responsibility to ensure there's enough room for the stack.

Actually it seems that there is a feature of gcc (yet unsupported by the AVR 
port) to switch on stack-checks at runtime each time new space on the stack is 
needed. Of course this would slow down execution, but I think that implementing 
this could be *very* helpful for debugging and testing purposes.

IMO, a crude implementation of this seems not to be very difficult: IIUC, one 
would need one assembler function that does not clobber any registers that 
checks whether the stack pointer happens to point to an address too close to 
the memory region allocated for static variables. In case of an overflow, it 
could call a function of avr-libc that handles the error. Additionally, IIUC, 
one then would only need a 2-lines code change in the prologue generator in 
avr.c in order to call the check-fuction each time additional space is 
allocated on the stack. I.e. one would then have an additional call instruction 
at the beginning of almost any function. IMO this would not be a too serious 
problem for code size (+4 byte/function) but would slow down excecution quite a 
bit.


Yours,

Björn




reply via email to

[Prev in Thread] Current Thread [Next in Thread]