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?
And how will simply moving the stack do that?
If it overflows, it will overflow - no matter where it is located!
Andrew Neil if I leave things as is, stack will be located on top of the RAM and .bss is located at the bottom. So when stack overflows it can grow right to the .bss section and will overwrite it, quietly. I have seen absolutely random bugs when IRQ happened on top of long function call chain and overwrote some memory location somewhere, causing an assertion later in different place.
If I relocate the stack as suggested, then when it overflows, HardFault Exception will be generated and everything will break loudly and immediately. I believe this is much better.
OK - so is this just a means to try to catch the event and, thence diagnose the problem?
If so, why not just set a memory access breakpoint just beyond the bottom of the stack...?
Andrew Neil, yes, it's just to spot the problem when it occurs.
>If so, why not just set a memory access breakpoint just beyond the bottom of the stack...?
Well, because "just beyond the bottom of the stack" can potentially be a correct location in .bss section.
And because stack overflow can actually occur not just beyond the bottom but 2 elements below or three or four and I won't be able to set access breakpoints on all of them.
What I did with this scatter file: I created a global variable and assigned a value to it. Its address was equal to the beginning of the RAM. When execution stopped at the beginning of the main, that global variable was correctly initialized.
Then I set an access breakpoint to it's address and saw that after reset this one memory location was several times used as a stack element, before global initialization was complete.
This looks strange and I'm not sure if it is safe.
Hello Roman,
You can add guard variables to protect stack frames: www.keil.com/.../armcc_chr1359124940593.htm
To stop an overflow, allocate enough memory (duh). Here are some tips on helping you estimate stack usage, and debugging techniques:
For ARM compiler 5: www.keil.com/.../armcc_chr1359124223721.htm
For ARM Compiler 6: www.keil.com/.../armclang_intro_hla1474359990839.htm www.keil.com/.../armclang_dev_chr1385112209448.htm
On top of that, you could use the Memory Protection Unit MPU, to prevent access to are below the stack, so you will hit a memory fault if you go to far.
>You can add guard variables to protect stack frames:
And I will have to check them periodically. How exactly is this better then my suggestion?
>On top of that, you could use the Memory Protection Unit MPU, to prevent access to are below the stack, so you will hit a memory fault if you go to far.
Unfortunately, I don't have MPU.
> www.keil.com/.../armcc_chr1359124223721.htm
Your link actually suggests: "Use RTSM, and define a region of memory where access is not allowed directly below your stack in memory, with a map file. If the stack overflows into the forbidden region, a data abort occurs, which can be trapped by the debugger."
So I'm trying to achieve this effect (similar to MPU actually) by relocating the stack. Why everybody keep discouraging me from that? :)
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.
well, because you are obviously finding it a struggle to do that!
so just trying to offer (potentially) easier paths.
As J Roof says, you taking a "path less trodden" - so it would be interesting to hear your results in the end.
Good luck.
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
I think I found out the source of my problem. I used default startup.s file where stack is created like this:
Stack_Size EQU 0x00000400 AREA STACK, NOINIT, READWRITE, ALIGN=3 Stack_Mem SPACE Stack_Size __initial_sp
And that just allocated Stack_Mem in the IRAM1 section, that's all. When I set Stack_Size equal to zero, it was still allocated in the IRAM1 section (and for some reason __initial_sp was equal to IRAM1 start + 8 but nevermind).
I edited my scatter file like this:
ARM_LIB_STACK 0x20000000 0x400 ; Stack region growing down { *(STACK) }
and now Stack_Mem area is placed into this ARM_LIB_STACK section. And that's it. Now initial steck pointer value is equal to the end of ARM_LIB_STACK section.
Unfortunately, now I have to set stack size in two places - in scatter file and in startup file, but I think that can be solved by using preprocessor or just by bearing with it.
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 ...
It should be possible for the Linker to export symbols to be visible to the source code...
eg, www.keil.com/.../armlink_pge1362065951495.htm