Default section placement

The sections are placed in the following order:

1. By attribute as follows:

   1. Read-only code.
   2. Read-only data.
   3. Read-write code.
   4. Read-write data.
   5. Zero-initialized data.
2. By input section name if they have the same attributes. Names are considered to be case-sensitive and are compared in alphabetical order using the ASCII collation sequence for characters.
3. By a tie-breaker if they have the same attributes and section names. By default, it is the order that armlink processes the section. You can override the tie-breaker and sorting by input section name with the FIRST or LAST input section attribute.

These rules mean that the positions of input sections with identical attributes and names included from libraries depend on the order the linker processes objects. This can be difficult to predict when many libraries are present on the command line. The --tiebreaker=cmdline option uses a more predictable order based on the order the section appears on the command line.

The base address of each input section is determined by the sorting order defined by the linker, and is correctly aligned within the output section that contains it.

The linker produces one output section for each attribute present in the execution region:

• One execute-only (XO) section if the execution region contains only XO sections.
• One RO section if the execution region contains read-only code or data.
• One RW section if the execution region contains read-write code or data.
• One ZI section if the execution region contains zero-initialized data.

The XO and RO output sections can be protected at run-time on systems that have memory management hardware. RO and XO sections can be placed in ROM or Flash.

Alternative sorting orders are available with the --sort=algorithm command-line option. The linker might change the algorithm to minimize the amount of veneers generated if no algorithm is chosen.

Example

The following scatter file shows how the linker places sections:

LoadRegion 0x8000
{
    ExecRegion1 0x0000 0x4000
    {
        *(sections)
        *(moresections)
    }
    ExecRegion2 0x4000 0x2000
    {
        *(evenmoresections)
    }
}

The order of execution regions within the load region is not altered by the linker.