Keil Logo

Technical Support

On-Line Manuals

Linker User Guide

Preface Overview of the Linker Linking Models Supported by armlink Image Structure and Generation The structure of an ARM ELF image Views of the image at each link stage Input sections, output sections, regions, and prog Load view and execution view of an image Methods of specifying an image memory map with the Image entry points Simple images Types of simple image Type 1 image structure, one load region and contig Type 2 image structure, one load region and non-co Type 3 image structure, multiple load regions and Section placement with the linker Default section placement Section placement with the FIRST and LAST attribut Section alignment with the linker Linker support for creating demand-paged files Linker reordering of execution regions containing Linker-generated veneers What is a veneer? Veneer sharing Veneer types Generation of position independent to absolute ven Reuse of veneers when scatter-loading Command-line options used to control the generatio Weak references and definitions How the linker performs library searching, selecti How the linker searches for the ARM standard libra Specifying user libraries when linking How the linker resolves references The strict family of linker options Linker Optimization Features Getting Image Details Accessing and Managing Symbols with armlink Scatter-loading Features Scatter File Syntax Linker Command-line Options Linker Steering File Command Reference Via File Syntax

How the linker resolves references

3.12 How the linker resolves references

When the linker has constructed the list of libraries, it repeatedly scans each library in the list to resolve references.

armlink maintains two separate lists of files. The lists are scanned in the following order to resolve all dependencies:
  1. The list of user files and libraries that have been loaded.
  2. List of ARM standard libraries found in a directory relative to the armlink executable, or the directories specified by --libpath, ARMCC5LIB, or ARMLIB.
Each list is scanned using the following process:
  1. Scan each of the libraries to load the required members:
    1. For each currently unsatisfied non-weak reference, search sequentially through the list of libraries for a matching definition. The first definition found is marked for processing in step 1.b.
      The sequential nature of the search ensures that the linker chooses the library that appears earlier in the list if two or more libraries define the same symbol. This enables you to override function definitions from other libraries, for example, the ARM® C libraries, by adding your libraries to the input file list. However you must be careful to consistently override all the symbols in a library member. If you do not, you risk the objects from both libraries being loaded when there is a reference to an overridden symbol and a reference to a symbol that was not overridden. This results in a multiple symbol definition error L6200E for each overridden symbol.
    2. Load the library members marked in step 1.a. As each member is loaded it might satisfy some unresolved references, possibly including weak ones. Loading a library member might also create new unresolved weak and non-weak references.
    3. Repeat these stages until all non-weak references are either resolved or cannot be resolved by any library.
  2. If any non-weak reference remains unsatisfied at the end of the scanning operation, generate an error message.
Related reference
Non-ConfidentialPDF file icon PDF versionARM DUI0377H
Copyright © 2007, 2008, 2011, 2012, 2014-2016 ARM. All rights reserved. 
  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.