Hello everyone, I am Pi Zi Heng, a serious tech enthusiast. Today, I will discuss linker files in embedded development.
In the previous lesson “Source Files (.c/.h/.s)”, I systematically introduced source files, which are typical input files in embedded projects. But are there other types of input files? Since I asked this question, the answer is definitely yes. The linker file I will discuss today belongs to another type of input file.
A linker file, as the name implies, is used during the linking phase of embedded projects. After the compilation process is complete (at this point, it has become machine-readable binary code), the linker organizes the binary data in an orderly fashion to form the final binary executable file, which will ultimately be downloaded into the chip’s internal non-volatile memory. The linker file is used to instruct the linker on how to organize the compiled binary data.
The linker file is closely related to the IDE. This article will use IAR EWARM as an example to introduce linker files, while linker files in other IDEs can be understood similarly.
1. Sections in Embedded Systems
Before discussing linker files, I must clarify a very important concept in embedded systems – sections. So, what is a section? The C or assembly source files we write contain various application codes, which can be categorized into many types based on functionality, such as constants, variables, functions, stacks, etc. A collection of code of the same type constitutes a section, which is the basic unit of data organization during linking by the linker. So, how many types of sections are there in a typical embedded system? Below is a list of all the default sections in IAR; those common sections will be mentioned in the subsequent introduction of linker files.
// Common Sections.bss // Holds zero-initialized static and global variables.CSTACK // Holds the stack used by C or C++ programs..data // Holds static and global initialized variables..data_init // Holds initial values for .data sections when the linker directive initialize is used.HEAP // Holds the heap used for dynamically allocated data..intvec // Holds the reset vector table.noinit // Holds __no_init static and global variables..rodata // Holds constant data..text // Holds the program code..textrw // Holds __ramfunc declared program code..textrw_init // Holds initializers for the .textrw declared section.// Less common Sections.exc.text // Holds exception-related code.__iar_tls.$$DATA // Holds initial values for TLS variables..iar.dynexit // Holds the atexit table..init_array // Holds a table of dynamic initialization functions.IRQ_STACK // Holds the stack for interrupt requests, IRQ, and exceptions..preinit_array // Holds a table of dynamic initialization functions..prepreinit_array // Holds a table of dynamic initialization functions.Veneer$$CMSE // Holds secure gateway veneers.// Even less common Sections.debug // Contains debug information in the DWARF format.iar.debug // Contains supplemental debug information in an IAR format.comment // Contains the tools and command lines used for building the file.rel or .rela // Contains ELF relocation information.symtab // Contains the symbol table for a file.strtab // Contains the names of the symbol in the symbol table.shstrtab // Contains the names of the sections.Note: For detailed explanations of the above sections, please refer to the Section reference section in the document located at IAR software installation directory\IAR Systems\Embedded Workbench xxx\arm\doc\EWARM_DevelopmentGuide.ENU.pdf.
2. Analyzing Linker Files
Now that we understand the concept of sections, we can delve into linker files. What is a linker file? A linker file is written according to the syntax specified by the IDE to instruct the linker on how to allocate each section’s location in the embedded system’s memory. As we know, the memory of embedded systems is mainly divided into two categories: ROM (non-volatile) and RAM (volatile). Therefore, these sections are categorized based on their storage location into two attributes: readonly and readwrite. Essentially, the job of the linker file is to place readonly sections in ROM and readwrite sections in RAM.
So, how do we write a linker file for a project? As mentioned earlier, linker files have syntax, and this syntax is specified by the IDE, so we must first grasp the syntax rules set by the IDE. The syntax rules for linker files are relatively simple, and the most commonly used keywords are the following eight:
// Verb keywordsdefine // Define various ranges and lengthsinitialize // Set section initialization methodplace in // Place section in a specific region (address allocated by linker)place at // Place section at a specific absolute address// Noun keywordsymbol // Identifier for various ranges and lengthsmemory // Identifier for the entire ARM memory space.region // Identifier for dividing a certain region in the entire ARM memory space.block // Identifier for a collection of multiple sectionsNote: For detailed explanations of the above linker syntax, please refer to the The linker configuration file section in the document located at IAR software installation directory\IAR Systems\Embedded Workbench xxx\arm\doc\EWARM_DevelopmentGuide.ENU.pdf.
At this point, we can start happily writing linker files. Are you feeling a bit impatient? Let’s do it in just three steps.
Here, we assume the MCU physical space is: ROM (0x0 – 0x1ffff), RAM (0x10000000 – 0x1000ffff). The linker requirements are as follows:
The interrupt vector table must be placed at the starting address of ROM 0x0, and must be aligned to 256 bytes. The STACK size must be 8KB, HEAP size must be 1KB, and must be aligned to 8 bytes. STACK must be placed at the starting address of RAM 0x10000000. The remaining sections should be placed in the correct region, with specific space allocated by the linker automatically.
2.1 Defining Physical Space
The first step is to define three non-overlapping spaces: ROM_region, RAM_region, and STACK_region, where ROM_region corresponds to the actual ROM space, and RAM_region and STACK_region together form the actual RAM space.
// Define physical space boundariesdefine symbol __ICFEDIT_region_ROM_start__ = 0x00000000;define symbol __ICFEDIT_region_ROM_end__ = __ICFEDIT_region_ROM_start__ + (128*1024 - 1);define symbol __ICFEDIT_region_RAM_start__ = 0x10000000;define symbol __ICFEDIT_region_RAM_end__ = __ICFEDIT_region_RAM_start__ + (64*1024 - 1);define symbol __ICFEDIT_intvec_start__ = __ICFEDIT_region_ROM_start__; // Define stack lengthdefine symbol __ICFEDIT_size_cstack__ = (8*1024);define symbol __ICFEDIT_size_heap__ = (1*1024); // Define specific space range for each regiondefine memory mem with size = 4G;define region ROM_region = mem:[from __ICFEDIT_region_ROM_start__ to __ICFEDIT_region_ROM_end__];define region STACK_region = mem:[from __ICFEDIT_region_RAM_start__ to __ICFEDIT_region_RAM_start__ + __ICFEDIT_size_cstack__ - 1];define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__ + __ICFEDIT_size_cstack__ to __ICFEDIT_region_RAM_end__];2.2 Defining Section Collections
The second step is to define custom section collections. Careful readers may notice that the right-hand side of the curly braces contains the system default sections introduced in the previous section. We will group sections with the same attributes into a block for convenience in the next placement step.
// Define stack block and its attributesdefine block CSTACK with alignment = 8, size = __ICFEDIT_size_cstack__ { };define block HEAP with alignment = 8, size = __ICFEDIT_size_heap__ { }; // Define section collection blockdefine block Vectors with alignment=256 { readonly section .intvec };define block CodeRelocate { section .textrw_init };define block CodeRelocateRam { section .textrw };define block ApplicationFlash { readonly, block CodeRelocate };define block ApplicationRam { readwrite, block CodeRelocateRam, block HEAP };Some may wonder why we define the two blocks CodeRelocate and CodeRelocateRam. Logically, these two blocks’ corresponding sections can be placed in ApplicationFlash and ApplicationRam, so why go to extra lengths? Those who have carefully studied my previous lesson on source files will know the answer. In that lesson, I introduced a function called init_data_bss() in the startup.c file, which initializes the CodeRelocateRam block, looking for the name of the CodeRelocate segment, which is clearer and more understandable than the system default textrw name.
2.3 Placing Section Collections
The third step is to handle the placement of those section collection blocks. Before placing the collection blocks, there are initialize manually statements. Why are these statements necessary? It relates back to the init_data_bss() function in the startup.c file, which the developer implements for initializing the data and bss segments, so we need to inform the IDE that you do not need to help me with the initialization work.
// Set initialization methodinitialize manually { readwrite };initialize manually { section .data};initialize manually { section .textrw };do not initialize { section .noinit }; // Place section collection blocksplace at start of ROM_region { block Vectors }; //place at address mem:__ICFEDIT_intvec_start__ { block Vectors };place in ROM_region { block ApplicationFlash };place in RAM_region { block ApplicationRam };place in STACK_region { block CSTACK };Of course, if you want the IDE to help you automatically initialize the data, bss, and textrw segments, you can replace the initialize manually statements with the following:
initialize by copy { readwrite, section .textrw };After setting the initialization method, it’s time to place the section collection blocks. The placement methods are mainly two: place in and place at, where the former is used to specify the placement of space blocks (without specifying a specific address), and the latter is for specifying a specific address.
Thus, a basic linker file is completed. Isn’t it so easy?
Bonus: Custom Sections
For those patient enough to read this far, I must reward you with a big surprise. What I’ve discussed so far is how to handle system default sections, but is it possible to define custom sections in the code? Imagine you have a requirement to allocate a 1KB updatable data area in your application, and you want to specify this data area to the address range of 0x18000 – 0x183ff. You need to define a 4 Byte readonly config block constant in the application pointing to the start address of this updatable data area (this config block will only be updated by an external debugger or bootloader). How can you achieve that?
// In C file/////////////////////////////////////////////////////// Use the @ operator to specify that variable myConfigBlock[4] goes into the custom .myBuffer sectionconst uint8_t myConfigBlock[4] @ ".myBuffer" = {0x00, 0x01, 0x02, 0x03}; // In Linker file/////////////////////////////////////////////////////// Define the custom mySection_region, and place .myBuffer in this regiondefine region mySection_region = mem:[from 0x0x18000 to 0x183ff];place at start of mySection_region { readonly section .myBuffer };We have successfully placed a constant from the code into a custom section. But how do we place functions from the code into a custom section? Keep reading.
// In C file/////////////////////////////////////////////////////// Use #pragma location to specify that function myFunction() goes into the custom .myTask section#pragma location = ".myTask"void myFunction(void){ __NOP();} // In Linker file/////////////////////////////////////////////////////// Place .myTask in mySection_regionplace in mySection_region { readonly section .myTask };It looks like we have succeeded. Lastly, there is one more note: if myConfigBlock is not referenced in the code, the IDE may ignore this variable during linking (the IDE thinks it’s unused and optimizes it out). So how can we force the IDE to link myConfigBlock? IAR has left a backdoor; in the options -> Linker -> Input tab, fill in the Keep symbols input box with the name of the object you want to force link (note that this is the object name in the code, not the custom section name in the linker file).
Note: For more details on the bonus content, please refer to the Pragma directives section in the document located at IAR software installation directory\IAR Systems\Embedded Workbench xxx\arm\doc\EWARM_DevelopmentGuide.ENU.pdf.
Thus, I have introduced linker files in embedded development. Where are the applause~~~