FILLing unused Memory with the GNU Linker

Posted on June 23, 2014 by Erich Styger

In many of my applications I use a CRC/checksum to verify that the code/flash on the target is not modified. For this, not only the code/data in flash counts, but as well all the unused gaps in the memory map. Instead to leave it up to the flasher/debugger (which usually erases it to 0xFF), I want to fill it with my pattern. The GNU linker is using the pattern 0x00 for unused bytes inside sections. So this post is about to use the GNU linker to ‘fill’ the uninitalized FLASH memory with a pattern.

FLASH with DeadBeef Pattern

=fill Linker File Command

The GNU linker has a way to fill a section. The GNU linker documenation lists the SECTIONS syntax as:

SECTIONS {
...
secname start BLOCK(align) (NOLOAD) : AT ( ldadr )
{ contents } >region :phdr =fill
...
}

The interesting thing is the =fill at the end: here I can specify an expression which then is used to fill the section:

=fill: Including =fill in a section definition specifies the initial fill value for that section. You may use any expression to specify fill. Any unallocated holes in the current output section when written to the output file will be filled with the two least significant bytes of the value, repeated as necessary. You can also change the fill value with a FILL statement in the contents of a section definition.

For example

.text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
    *(.eh_frame)

    KEEP (*(.init))
    KEEP (*(.fini))

    . = ALIGN(4);

    _etext = .;        /* define a global symbols at end of code */
  } > m_text =0xEE

Will fill my section with the 0xEE byte pattern. I can verify this when I compare the generated S19 files (see “Binary (and S19) Files for the mbed Bootloader with Eclipse and GNU ARM Eclipse Plugins“):

Inserted Fill Byte

❗ The =fill applies only *inside* an output section, so does not fill the space between output sections!

FILL() Linker Command

The =fill applies to the output section. But if I want to fill different parts within an output section, then the FILL command should be used:

FILL(expression): Specify the “fill pattern” for the current section. Any otherwise unspecified regions of memory within the section (for example, regions you skip over by assigning a new value to the location counter ‘.’) are filled with the two least significant bytes from the expression argument. A FILL statement covers memory locations after the point it occurs in the section definition; by including more than one FILL statement, you can have different fill patterns in different parts of an output section.

My favorite FILL command is this one:

FILL(0xDEADBEEF)

FILL(0xDEADC0DE)

🙂

Filling Memory Outside Sections

While the above =fill and FILL() examples are fine, they only fill *inside* a section.

For example for my KL25Z I have following MEMORY defined in the linker file:

MEMORY {
  m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x000000C0
  m_cfmprotrom  (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
  m_text      (RX) : ORIGIN = 0x00000410, LENGTH = 0x0001FBF0
  m_data      (RW) : ORIGIN = 0x1FFFF000, LENGTH = 0x00004000
}

The linker will place my code and constant data into the m_text output section. I will not fill up all the 128 KByte of FLASH, so the end of m_text will not be filled with the above examples. So how to fill the rest of m_text up to the address 0x1’FFFF (end of FLASH memory)?

The trick is to add a special output section at the end which then gets filled with a pattern. For this I need find what is the last section put into m_text. Looking at my linker script file there is this:

  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);

    ___ROM_AT = .;
  } > m_text

So .fini_array is the last thing for m_text, and it defines a linker symbol ___ROM_AT which marks the end of the ROM. What I do now is to create a new output section .fill and move the ___ROM_AT symbol:

  .fini_array :
  {
    PROVIDE_HIDDEN (__fini_array_start = .);
    KEEP (*(SORT(.fini_array.*)))
    KEEP (*(.fini_array*))
    PROVIDE_HIDDEN (__fini_array_end = .);

    /*___ROM_AT = .; */
  } > m_text
  
  .fill :
  {
    FILL(0xDEADBEEF);
    . = ORIGIN(m_text) + LENGTH(m_text) - 1;
    BYTE(0xAA)
    ___ROM_AT = .;
  } > m_text

Using the FILL command to define the pattern (0xdeadbeef)
Setting the current section cursor (.) at the last byte of the m_text MEMORY area
Writing a value to that location with the BYTE() command. Note that this byte is technically needed, as the linker needs to have something in the output section.
Defining the ___ROM_AT symbol. My linker file is using that symbol later. If your linker file does not need this, you do not need this line.

After that, I get the unused FLASH filled with a DEADBEEF pattern:

Filled FLASH Memory with 0xdeadbeef

And the end has as expected at 0x1FFFF the 0xAA byte:

0x1FFFF filled with 0xAA

Summary

Filling the unused FLASH memory with a defined pattern is a very useful thing: it makes the memory defined e.g. for a checksum calculation. Additionally it can increase the reliability of an application: I can fill the FLASH memory with an illegal instruction or HALT instruction: so when my application would jump into undefined memory, I can bring the system to a screeching halt.

To use a fill pattern inside a section is very easy with the GNU linker (ld). To fill unused memory outside of output sections, I’m using a dedicated .fill section as shown in this post.

Happy FILLing 🙂

Links:

GNU Linker Manual (pdf)
Similar idea using fill section: blog.hrbacek.info/2013/12/28/filling-unused-memory-area-using-gnu-linker-script/

26 thoughts on “FILLing unused Memory with the GNU Linker”

robotjosh on December 2, 2014 at 18:20 said:

How do you deal with the data sections that use AT(__ROM_AT), actually getting put into flash section and cause an overlap? If you use =fill in the last text section, it doesn’t get used because the data sections are put next. If you use the .fill section in the text area, it will fill to the end of flash but then try to load the data section after the end of flash. If you use the .fill section in the data area, it will fill up to the size of the sram. I don’t see a way to have uninitialized data in flash and have a fill to the end of flash.

LikeLike

Reply ↓
- Erich Styger on December 2, 2014 at 18:41 said:
  
  Hmm, could you not create an additional section in the linker file for this?
  
  LikeLike
  
  Reply ↓
Pingback: CRC Checksum Generation with ‘SRecord’ Tools for GNU and Eclipse | MCU on Eclipse
Ankur on March 27, 2017 at 18:55 said:

Hi Erich,

Followed the steps but the project did not build -> “region m_text overflowed with text and data”. Although got some idea after reading above comment…but didn’t get the complete idea. What I am doing wrong ?

LikeLike

Reply ↓
- Erich Styger on March 27, 2017 at 21:10 said:
  
  It means that the pieces going into m_text were too large. I recommend that you artificially increase the m_text memory are in the linker file in order to sucessfully link. Then inspect the linker .map file what is causing the problem (check the objects going into m_text).
  I hope this helps,
  Erich
  
  LikeLike
  
  Reply ↓
srijan Banerjee on August 18, 2017 at 20:42 said:

Hi Erich,

Thanks for pointing me to this post of yours.

I need to fill up to a preset size in flash not the entire available space (context: I have different partitions in flash to hold different portions of software).

Is there a way to use FILL(Expression) in a manner that will allow to fill upto a desired size rather than the whole available space allocated to ps7_ram_0_S_AXI_BASEADDR (m_text in your case).

regards,
Srijan

LikeLike

Reply ↓
- Erich Styger on August 19, 2017 at 10:15 said:
  
  Hi Srijan,
  you can fill the memory up to any boundary you want. See the example at the end of the article which fills up to the __ROM_AT symbol. The thing is that you define a symbol which you can calculate and then use the FILL command up to that symbol. Do this for each of your different partitions.
  
  LikeLike
  
  Reply ↓
miltonid on December 27, 2017 at 14:31 said:

Hi Erich I has been trying to fill the unused flash in FRDM-K64F.

The linker file of frdm-kl25z has a little difference with the frdm-k64f.

When I tried to use the FILL command my hex file was filled with my pattern but my microcontroller not run with these binary.

I’m usign Processor expert with KDS in the linker file has not the line ___ROM_AT = .; *

.fini_array :
{
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(SORT(.fini_array.*)))
KEEP (*(.fini_array*))
PROVIDE_HIDDEN (__fini_array_end = .);
} > m_text

LikeLike

Reply ↓
- Erich Styger on December 29, 2017 at 07:44 said:
  
  As described in the article, the symbol __ROM_AT might not be present/needed. It is used as a symbol for the next section/segment allocation, because with FILL I move the memory segment addresses.
  Have you checked why or what does not run with your binary using the debugger?
  
  LikeLike
  
  Reply ↓
  - miltonid on December 29, 2017 at 12:09 said:
    
    When a use the debugger using the binary filled I found that the program is suspended.
    Thread #1 (Running: User Request)
    
    When I paused using the debugger I detected that the program was stopped in system_MK64F12.c
    
    while((MCG->S & MCG_S_LOCK0_MASK) == 0x00U) { /* Wait until PLL is locked*/
    
    LikeLike
    
    Reply ↓
    - Erich Styger on December 29, 2017 at 12:39 said:
      
      That very likely means that something else is wrong with your application. If you are stuck at this location it means that your clock configuration is not matching your hardware.
      
      LikeLike
  - miltonid on January 4, 2018 at 20:16 said:
    
    Hi Erich, I have tested with new empty project and I get the same behavior when I modify the linker file. I’ll continue working for solve this issue.
    
    LikeLike
    
    Reply ↓
    - marknuse on February 19, 2019 at 19:00 said:
      
      Got same issue with S32K116. When using FILL, application halts.
      
      LikeLike
    - Erich Styger on February 19, 2019 at 20:25 said:
      
      Where does the application halt? Could it be that you filled areas in the memory map which have something special in it and are not normal FLASH?
      
      LikeLike
Robert Poor on August 9, 2018 at 01:19 said:

Super useful as always! One tiny typo:
“And the end has as expected at 0x1FFFF the 0x00 byte:”
should be
“And the end has as expected at 0x1FFFF the 0xAA byte:”

LikeLike

Reply ↓
- Erich Styger on August 9, 2018 at 07:21 said:
  
  Hi Robert,
  many thanks, fixed now.
  Erich
  
  LikeLike
  
  Reply ↓
andril on November 28, 2018 at 11:01 said:

Hi Erich,

Can we use the FILL command to initialize the complete SRAM Data memory to zero. If so, can you please let me know how ? I wanted to do this as upon every reset, i would like the RAM to be void of garbage values.
Thanks,

LikeLike

Reply ↓
- Erich Styger on November 28, 2018 at 12:25 said:
  
  Hi,
  you better do this in the startup code, see https://mcuoneclipse.com/2012/11/11/optimizing-the-kinetis-gcc-startup/
  Erich
  
  LikeLike
  
  Reply ↓
Cheney on April 26, 2019 at 05:44 said:

Hi, Erich:

Do you know how to fill the unused memory in S32DS(S32K144)?
The ld script i added is showed below.

/* Section used by the libgcc.a library for fvp4 */
.ARM :
{
__exidx_start = .;
*(.ARM.exidx*)
__exidx_end = .;
} > m_text

.fini_array :
{
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(SORT(.fini_array.*)))
KEEP (*(.fini_array*))
PROVIDE_HIDDEN (__fini_array_end = .);

/*___ROM_AT = .; */
} > m_text

.fill :
{
FILL(0xDEADBEEF);
. = ORIGIN(m_text) + LENGTH(m_text) – 1;
BYTE(0xAA)
___ROM_AT = .;
} > m_text

__etext = .; /* Define a global symbol at end of code. */
__DATA_ROM = .; /* Symbol is used by startup for data initialization. */

But generated file is not correct. Some data is added after the fill data. I don’t know how to modify the ld script， Could you give me some tips.

BTW，I found another way to fill unused memory.
objcopy -O binary –pad-to=0x80000 –gap-fill=0xff $SOURCES $TARGET
We can add the option in S32DS. Now it can generate the target code correctly.

LikeLike

Reply ↓
- Erich Styger on April 27, 2019 at 06:01 said:
  
  Using objcopy is a good approach too. About the linker file: you have to check what kind of symbols/data is placed after the fill section to understand what is going on. Check the linker .map file.
  
  LikeLike
  
  Reply ↓
O.Agudia (@oagudia87) on November 12, 2022 at 19:12 said:

Hi, Erich:

Any way to do the same by using the .icf file in IAR environment. I have tried it in STCUBE and works perfect:

.fill :
{
_FillStartAddress = .; /* Provides start address of Filled location */
FILL(0xDEADBEEF);
. = ORIGIN(FLASH) + LENGTH(FLASH) – _FillStartAddress – 1; /* Fill till end of rom */
BYTE(0xAA) /* NO Quitar */
} >FLASH

but I have no idea how to do it with IAR IDE.

Thanks for your blog! it is amazing!

LikeLike

Reply ↓
- Erich Styger on November 13, 2022 at 08:58 said:
  
  The issue is that IAR is not using GNU tools, but their proprietary compiler and linker. So you have to check the IAR linker what linker file syntax it supports. I do not use IAR tools for years on my side, because the GNU tools imho are way better, sorry.
  
  LikeLike
  
  Reply ↓
Chris on October 5, 2023 at 14:37 said:

I stumbled on this ~10 year old post while searching how to pad an image to an even number of 256 bytes (I’m porting some code to an stm32h7). One of you remarks reminded me of something we used to do when I was a young engineer on 8051 projects. We would fill unused all the unused memory with 0x02. The reason was that “0x020202” was the instruction “LJMP 0x0202”. And we would put a function at 0x0202 that would reset the microprocessor.

-Chris “The Stumbler” Lott
Sacheon, South Korea

LikeLike

Reply ↓
- Erich Styger on October 5, 2023 at 17:09 said:
  
  Well, old post still can have a purpose :-). Similar to your idea, I do fill memory sometimes with ‘BKPT’ instruction patterns: if it runs on it, it will trigger the debugger if a debugger is attached, otherwise it will cause a hardfault and reset.
  
  LikeLike
  
  Reply ↓
  - Chris Lott on October 5, 2023 at 22:36 said:
    
    Now that I know you’re alive and kicking, could you point me in the right direction on how to do that, by chance? When I flippantly commented last night, I thought my issue was common and would have a ready, if not complicated and obtuse, solution. I searched around an hour or so and came up mostly empty-handed.
    
    There are lots of methods like you describe for filling sections and filling between sections. And there are methods to align sections on specified N-byte boundaries. But I can’t find how to “fill-up” or “round-up” a section to the next alignment boundary. I found one fella who had a similar need, and the answer was discouraging and involved a technique that I’m not familiar with — like defining a new section to force this behavior and then deleting that section.
    
    At the moment, I use a short post processing tool I wrote a few years ago that massages the binary file and adds padding if necessary.
    
    I like your hard-fault breakpoint solution. I don’t do ARM assembly but I assume that’s a single word operation? The problem with the 8051 and other 8-bit MCUs was that instructions could be various sizes. With a long string of 0x02, yon didn’t care exactly where an errant PC landed (within reason). Unlike had you tried to LJMP to 0x0000. This wasn’t something did on every project, but some were kind of important like in the guidance section of a small test rocket, where a restart, while not ideal, was much preferred over a freeze.
    
    LikeLike
    
    Reply ↓
    - Erich Styger on October 6, 2023 at 05:40 said:
      
      The ARM BKPT instruction is a two byte instruction, and instructions have to be word aligned anyway. So it is easy to have that approach applied. As a RISC core, all instructions have the same length. Another approach is to use an illegal instruction for that core (e.g. using an FPU instruction for a non-FPU variant).
      I agree that fiddling whit the GNU linker files is sometimes a pain. What I’m using instead is using the SRecord tool to manipulate the binary (you find several article on my blog about SRecord).
      
      LikeLike