3

I want to reserve/allocate a range of memory in RAM and the same application should not overwrite or use that range of memory for heap/stack storage. How to allocate a range of memory in ram protected from stack/heap overwrite? I thought about adding(or allocating) an array to the application itself and reserve memory, But its optimized out by compiler as its not referenced anywhere in the application.

I am using ARM GNU toolchain for compiling.

ted
  • 3,911
  • 3
  • 26
  • 49
  • 2
    What do you want to achieve with this? Have you tried making the array volatile. The compiled should not optimize it out then. – domen Jun 09 '14 at 10:53
  • Have you checked this: http://stackoverflow.com/questions/2219829/how-to-prevent-gcc-optimizing-some-statements-in-c. Like domen said, make it `volatile`. – bytefire Jun 09 '14 at 10:57
  • *What do you want to achieve with this?* – ArjunShankar Jun 09 '14 at 10:58
  • 1
    http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem – auselen Jun 09 '14 at 11:01
  • I have another application which has access to the ram of this micrcontroller. So I want to make sure that this memory shouldn't got corrupted by stack or heap. Is volatile is going to help If I didn't access the variable in that application. When I used volatile for the array it got removed(or not allocated any memory) by the compiler/linker because its is not used any where in the program. PS- I am forced to pass -fdata-section to the gcc, thats the reason the volatile is removed by linker. – ted Jun 09 '14 at 12:05

1 Answers1

4

There are several solutions to this problem. Listing in best to worse order,

  1. Use the linker
  2. Annotate the variable
  3. Global scope
  4. Volatile (maybe)

Linker script

You can obviously use a linker file to do this. It is the proper tool for the job. Pass the linker the --verbose parameter to see what the default script is. You may then modify it to precisely reserve the memory.

Variable Attributes

With more recent versions of gcc, the attribute used will also do what you want. Most modern gcc versions will support this. It is also significantly easier than the linker script; but only the linker script gives precise control over the position of the hole in a reliable manner.

Global scope

You may also give your array global scope and the compiler should not eliminate it. This may not be true if you use link time optimization.

Volatile

Theoretically, a compiler may eliminate a static volatile array. The volatile comes into play when you have code involving the array. It modifies the access behavior so the compiler will never caches access to that range. Dr. Dobbs on volatile At least the behavior is unclear to me and I would not recommend this method. It may work with some versions (and optimization levels) of the compiler and not others.

Limitations

Also, the linker option -gc-sections, can eliminate space reserved with either the global scope and the volatile methods as the symbol may not be annotated in any way in object formats; see the linker script (KEEP).

Only the Linker script can definitely restrict over-writes by the stack. You need to position the top of the stack before your reserved area. Typically, the heap grows up and the stack grows down. So these two collide with each other. This is particular to your environment/C library (for instance newlib is the typical ARM bare metal library). Looking at the linker file will give the best clue to this.

My guess is you want a fallow area to reserve for some sort of debugging information in the event of a system crash? A more explicit explaination of you problem would be helpful. You don't seem to be concerned with the position of the memory, so I guess this is not hardware related.

artless noise
  • 21,212
  • 6
  • 68
  • 105
  • 1
    Er, sorry, I see your reason is you want to reserve the memory for another CPU. The best option is the linker script. You can position the stack and heap far from the other CPUs area. You need an MMU, etc to be strictly protected from an over-write. Also, the position of the memory will probably be very important between builds. The *linker script* will enforce this. – artless noise Jun 09 '14 at 17:24