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

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

Re: AW: [avr-gcc-list] stack layout


From: Russell Shaw
Subject: Re: AW: [avr-gcc-list] stack layout
Date: Fri, 24 Jun 2005 20:05:48 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1

Haase Bjoern (PT-BEU/EMT) * wrote:
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.

At strategic points you could do:

  size_t freespace = alloca(0) - sbrk(0) + 1;




reply via email to

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