11.3.1 Mapping Input Sections to Output Sections

Input sections are grouped and mapped into output sections, according to the section map. When an output section contains several different input sections, the exact ordering of input sections may be important. For example, consider the following output section definition:

/*
** User Code and Library Code
*/
.text :
{
      *(.init);
      *(.user_init);
      *(.libc) *(.libm) *(.libdsp); /* keep together in this order */
      *(.lib*);
} >program

Here the output section named .text is defined. Notice that the contents of this section are specified within curly braces {}. After the closing brace, >program indicates that this output section should be assigned to memory region program.

The contents of output section .text may be interpreted as follows:

• Input sections named .init are collected and mapped into the output section. By convention, there is only one .init section, and it contains the startup code for an application. It appears first in the output section (i.e., at the lowest address) so that its address is readily available if necessary.
• Input sections named .user_init are collected and mapped into the output section. These sections are created by the compiler and refer to functions that have been decorated with the user_init attribute. Their position within the output section is not critical, but since they are associated with section.init, they are located immediately after.
• Input sections named .libc, .libm and .libdsp are collected and mapped into the output section. Grouping these sections ensures locality of reference for the run-time library functions, so that PC-relative instructions can be used for maximum efficiency.
• Input sections which match the wildcard pattern .lib* are collected and mapped into the output section. This includes libraries such as the peripheral libraries (which are allocated in section .libperi).