Modules and sections
Each relocatable object file contains one module, which consists of:
Several sections of code or data
Runtime attributes specifying various types of information, for example, the version of the runtime environment
Optionally, debug information in DWARF format
A symbol table of all global symbols and all external symbols used.
Note
In a library, each module (source file) should only contain one single function. This is important if you want to override a function in a library with a function in your own application. The linker includes modules only if they are referred to from the rest of the application. If the linker includes a library module that contains several functions because one function is referred to, and another function in that module should be overridden by a function defined by your application, the linker issues a “duplicate definitions” error.
A section is a logical entity containing a piece of data or code that should be placed at a physical location in memory. A section can consist of several section fragments, typically one for each variable or function (symbols). A section can be placed either in RAM or in ROM. In a normal embedded application, sections that are placed in RAM do not have any content, they only occupy space.
Each section has a name and a type attribute that determines the content. The type attribute is used (together with the name) for selecting sections for the ILINK configuration.
The main purpose of section attributes is to distinguish between sections that can be placed in ROM and sections that must be placed in RAM:
| ROM sections |
| RAM sections |
In each category, sections can be further divided into those that contain code and those that contain data, resulting in four main categories:
| Normal code |
| Constants |
| Code copied to RAM |
| Variables |
readwrite data also has a subcategory—zi|zeroinit—for sections that are zero-initialized at application startup.
Note
In addition to these section types—sections that contain the code and data that are part of your application—a final object file will contain many other types of sections, for example, sections that contain debugging information or other type of meta information.
A section is the smallest linkable unit—but if possible, ILINK can exclude smaller units—section fragments—from the final application. For more information, see Keeping modules, and Keeping symbols and sections.
At compile time, data and functions are placed in different sections. At link time, one of the most important functions of the linker is to assign addresses to the various sections used by the application.
The IAR build tools have many predefined section names. For more information about each section, see Section reference.
You can group sections together for placement by using blocks. See define block directive.