[Top][All Lists]
[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
- AW: [avr-gcc-list] stack layout,
Haase Bjoern (PT-BEU/EMT) * <=