AnsweredAssumed Answered

How to place stack at the start of RAM using Coldfire linker file.

Question asked by C Stevens on Feb 18, 2014
Latest reply on Mar 21, 2014 by Jorge_Gonzalez

I would like to place my stack at the bottom of RAM, before any other data segments, to protect against stack overflow problems.  How can I tell the linker to reserve some space at the beginning of RAM for my stack?  When I try as described below, the Flash programmer rejects the resulting S19 file.

 

By default, the linker file places the stack right above the data segment.  But in that situation, if the stack overflows (growing down due to nesting function calls too deeply or an unexpected worst case of many ISRs at the same time) this will lead to silently overwriting parts of the data segment.  I don't want to detect this via writing some sentinel values to the stack and occasionally checking to see if they have been overwritten.  I want to prevent my data from being (possibly undetectably) overwritten.  If the stack is located at the bottom of RAM instead of the top, then when the stack overflows below the start of physical RAM, I will get an immediate exception and hardware reset.  The fact that my processor is resetting because of a stack overflow indicates that my code still has a problem that needs to be fixed, but a hardware reset will prevent the program from silently just continuing to run after data corruption.

 

Here is an extract from my .LCF file for Codewarrior for Coldfire 7.2.2.

 

  .text :

  {

    *(.init)

    *(.text)

    *(.rodata)

  } > rom

 

  .stack :

  {

    ___SP_END = .;

    . = . + ___stack_size;

    . = ALIGN(4);

    __SP_INIT = .;

    ___SP_AFTER_RESET = __SP_INIT;

  } > ram

 

  .data : AT(___DATA_ROM)

  {

    ___DATA_RAM = .;

    *(.data)

    . = ALIGN(4);

    ___DATA_END = .;

  } >> ram

 

The .xMAP shows that the stack is located at the beginning of RAM. Yay!

 

But the resulting .S19 file is filled with records that explicitly write ___stack_size worth of 0 bytes to RAM.  That wouldn't really be a problem, but the Flash Programmer gets mad at the S19 file because it is only allows specifying Flash locations not RAM locations.  The LCF file does not use ZERO_FILL_UNINITIALIZED.  It seems to be that line ". = . + ___stack_size" that moves the location has the side effect of writing all those 0 bytes.  Here is an extract of the generated S19 file.  You've got the end of the .text segment and then all those explicit zeroes starting at RAM 0x20000000.


S325000114A04572726F723A20466C61736820636F7079206661696C6564000A3F3F3F0A446FEF

S325000114C0776E6C6F6164204661696C6564000000000001AC002020202020202020202828FE

S325000114E0282828202020202020202020202020202020202020881010101010101010101005

S325000115001010101010444444444444444444441010101010101041414141414101010101D2

S325000115200101010101010101010101010101010110101010101042424242424202020202A0

S321000115400202020202020202020202020202020210101010200000000000000008

S325200000000000000000000000000000000000000000000000000000000000000000000000BA

S3252000002000000000000000000000000000000000000000000000000000000000000000009A

S3252000004000000000000000000000000000000000000000000000000000000000000000007A

S3252000006000000000000000000000000000000000000000000000000000000000000000005A

S3252000008000000000000000000000000000000000000000000000000000000000000000003A

S325200000A000000000000000000000000000000000000000000000000000000000000000001A

S325200000C00000000000000000000000000000000000000000000000000000000000000000FA

S325200000E00000000000000000000000000000000000000000000000000000000000000000DA

S325200001000000000000000000000000000000000000000000000000000000000000000000B9

S32520000120000000000000000000000000000000000000000000000000000000000000000099

 

How do I tell the linker to reserve some space at the beginning of RAM for my stack without causing all those 0 bytes to be written to the S19 file?

Outcomes