DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Migrate, Modernize and Build Java Web Apps on Azure: This live workshop will cover methods to enhance Java application development workflow.

Modern Digital Website Security: Prepare to face any form of malicious web activity and enable your sites to optimally serve your customers.

Kubernetes in the Enterprise: The latest expert insights on scaling, serverless, Kubernetes-powered AI, cluster security, FinOps, and more.

A Guide to Continuous Integration and Deployment: Learn the fundamentals and understand the use of CI/CD in your apps.

Related

  • Configuring Spark-Submit
  • Exploring Exciting New Features in Java 17 With Examples
  • What Do You Mean by Debugging in C?
  • Python Variables Declaration

Trending

  • Evolution of Software Architecture: From Monoliths to Microservices and Beyond
  • Performance of ULID and UUID in Postgres Database
  • Converting ActiveMQ to Jakarta (Part 1)
  • Use Amazon Bedrock and LangChain To Build an Application To Chat With Web Pages

FILLing unused Memory with the GNU Linker

Erich Styger user avatar by
Erich Styger
·
Jun. 23, 14 · Interview
Like (0)
Save
Tweet
Share
10.7K Views

Join the DZone community and get the full member experience.

Join For Free

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 0×00 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

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 =fil l 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

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)

or

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 0×1′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

filled flash memory with 0xdeadbeef

and the end has as expected at 0x1ffff the 0×00 byte:

0x1ffff filled with 0xaa

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 fill ing :-)

links:

  • gnu linker manual ( pdf )
  • similar idea using fill section: http://blog.hrbacek.info/2013/12/28/filling-unused-memory-area-using-gnu-linker-script/
GNU linker Memory (storage engine) GNU

Published at DZone with permission of Erich Styger, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Configuring Spark-Submit
  • Exploring Exciting New Features in Java 17 With Examples
  • What Do You Mean by Debugging in C?
  • Python Variables Declaration

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: