I want to protect myself from stack overflow. From several articles I got the idea that I can locate the stack in the bottom of the RAM, before .bss section. Since on Cortex M stack grows down, on stack overflow my code will attempt to write in non-existing memory and I'll get an exception. And exception is much better than quit corruption of static data.
I used project for stm32f10x, so 0x08000000 is the beginning of the flash and 0x20000000 is the beginning of RAM.
Using www.keil.com/.../armlink_pge1362065977713.htm i was able to come up with scatter file like this one (based on generated file):
LR_IROM1 0x08000000 0x00020000 { ; load region size_region ER_IROM1 0x08000000 0x00020000 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) .ANY (+RO) } ARM_LIB_STACK 0x20000000 EMPTY 0x400 ; Stack region growing down { } RW_IRAM1 0x20000408 0x00005000-0x408 { ; RW data .ANY (+RW +ZI) } }
Here I create the stack area of size 0x400 and the rest of the RAM is given to IRAM1 section. So far so good, it seems to work. However, there are three things that puzzle me:
1) When I tried to do "RW_IRAM1 0x20000400 0x00005000-0x400", I got linker about overlapping regions of ARM_LIB_STACK and RW_IRAM1 (although I can't reproduce it right now wich is even more odd).
2) I presumed that this way the beginning of the stack would be exactly at the end of the stack region. However, when I look in the first entry of the vector table, I see there a value of 0x20000410. And this value seems to change not according the size of the stack region but according the beginning of the RW_IRAM1 region.
3) I had to edit my startup.s file and set Stack_Size equal to 0; otherwise initial stack pointer value in the vector table was a sum of 0x20000410 and Stack_Size.
So my question is - am I on the right track? Is this the correct way to split .bss and stack regions? What is causing this dispersancy between stack region and and initial stack pointer value from vector table? My test global variable is placed at the beginning of the IRAM1 and it is initialized correctly, can I pretend that everything is just fine?
This is obviously an issue nobody has ever considered.
But seriously, it's not difficult to position the stack at an alternative location. What you're suggesting doesn't seem very advantageous to me though and I can't see it working as you think it might.
Without a memory management unit, you'll likely to always have the danger of experiencing a stack overflow without the ability to 100% guarantee picking it up. I've always followed the approach of calculating worst expected case use and adding something extra for safety.
J Roof, let me explain again than: I suggest using this kind of memory map:
top of RAM <potentially empty space> .bss stack (growing down) bottom of RAM
So when stack overflows it writes to the nonexisting memory below bottom of RAM and triggers HardFault exception.
It won't work in three cases: 1) If there is memory below bottom of RAM (seems unlikely) 2) MMU does not trigger exception when nonexisting memory is accessed (seems very unlikely) 3) User code writes above initial top of the stack (i.e. negative array index access). Possible, but not very frequent.
>I've always followed the approach of calculating worst expected case use and adding something extra for safety.
That can be really hard when we use IRQ and virtual calls; I suspect that's why not even gcc and clang don't do it statically.
There is a fourth:
4) A bad pointer happens to be pointing into the Stack somewhere
Andrew Neil, well, yeah, but 3 and 4 aren't actually stack overflows, so these are not the problems I'm trying to solve right now.
Agreed.
But are you sure that your problem actually is a Stack overflow?
If it's actually one of these, than all this work will be to no avail ...
Andrew Neil I guess I should've stated my problem more firmly. My problem was as follows: I have an IRQ handler which is triggered sporadically by some external event. If I am unlucky and it gets called on top of sufficiently deep function call, stack overflows and IRQ handler overwrite part of .bss section. Quietly.
Then I got an assertion in completely different place or (and that's even worse) I don't and my program is broken without me knowing it.