5.2.6. Resolving multiple matches
If a section matches more than one execution region, matches are resolved as described below. However, if a unique match cannot be found, the linker faults the scatter-loading description. Each section is selected by a module_select_pattern and an input_section_selector.
Examples of module_select_pattern specifications are:
* matches any module or library
*.o matches any object module
math.o matches the math.o module
*armlib* matches all ARM-supplied C libraries
*math.lib matches any library path ending with math.lib. For example, C:\apps\lib\math\satmath.lib.
Examples of input_section_selector specifications are:
+RO is an input section attribute that matches all RO code and all RO data
+RW,+ZI is an input section attribute that matches all RW code, all RW data, and all ZI data
BLOCK_42 is an input section pattern that matches the assembly file area named BLOCK_42.
Note
The compiler produces areas that can be identified by input section patterns such as .text, .data, .constdata, and .bss. These names, however, might change in the future and you must avoid using them.
If you want to match a specific function or extern data from a C or C++ file, either:
compile the function or data in a separate module and match the module object name
use #pragma arm section or __attribute__ to specify the name of the section containing the code or data of interest. See Pragmas in the Compiler Reference Guide for more information on pragmas.
The following variables are used to describe multiple matches:
In the case of multiple matches, the linker determines the region to assign the input section to on the basis of the module_select_pattern and input_section_selector pair that is the most specific.
For example, if input section A matches m1,s1 for execution region R1, and A matches m2,s2 for execution region R2, the linker:
assigns A to R1 if m1,s1 is more specific than m2,s2
assigns A to R2 if m2,s2 is more specific than m1,s1
diagnoses the scatter-loading description as faulty if m1,s1 is not more specific than m2,s2 and m2,s2 is not more specific than m1,s1.
The sequence armlink uses to determine the most specific module_select_pattern, input_section_selector pair is as follows:
For the module selector patterns:
m1 is more specific than m2 if the text string m1 matches pattern m2 and the text string m2 does not match pattern m1.
For the input section selectors:
If s1 and s2 are both patterns matching section names, the same definition as for module selector patterns is used.
If one of s1, s2 matches the input section name and the other matches the input section attributes, s1 and s2 are unordered and the description is diagnosed as faulty.
If both s1 and s2 match input section attributes, the determination of whether s1 is more specific than s2 is defined by the relationships below:
ENTRY is more specific than RO‑CODE, RO‑DATA, RW‑CODE or RW‑DATA
RO‑CODE is more specific than RO
RO‑DATA is more specific than RO
RW‑CODE is more specific than RW
RW‑DATA is more specific than RW
There are no other members of the (s1 more specific than s2) relationship between section attributes.
For the module_select_pattern, input_section_selector pair, m1,s1 is more specific than m2,s2 only if any of the following are true:
s1 is a literal input section name that is, it contains no pattern characters, and s2 matches input section attributes other than +ENTRY
m1 is more specific than m2
s1 is more specific than s2.
This matching strategy has the following consequences:
Descriptions do not depend on the order they are written in the file.
Generally, the more specific the description of an object, the more specific the description of the input sections it contains.
The input_section_selectors are not examined unless:
Object selection is inconclusive.
One selector fully names an input section and the other selects by attribute. In this case, the explicit input section name is more specific than any attribute, other than ENTRY, that selects exactly one input section from one object. This is true even if the object selector associated with the input section name is less specific than that of the attribute.
Example 5.2 shows multiple execution regions and pattern matching.
Example 5.2. Multiple execution regions and pattern matching
LR_1 0x040000
{
ER_ROM 0x040000 ; The startup exec region address is the same
{ ; as the load address.
application.o (+ENTRY) ; The section containing the entry point from
} ; the object is placed here.
ER_RAM1 0x048000
{
application.o (+RO‑CODE) ; Other RO code from the object goes here
}
ER_RAM2 0x050000
{
application.o (+RO‑DATA) ; The RO data goes here
}
ER_RAM3 0x060000
{
application.o (+RW) ; RW code and data go here
}
ER_RAM4 +0 ; Follows on from end of ER_R3
{
*.o (+RO, +RW, +ZI) ; Everything except for application.o goes here
}
}