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

Weak references and definitions

3.8 Weak references and definitions

Weak references and definitions provide additional flexibility in the way the linker includes various functions and variables in a build.

Weak references and definitions are typically references to library functions.
Weak references
If the linker cannot resolve normal, non-weak, references to symbols from the content loaded so far, it attempts to do so by finding the symbol in a library:
  • If it is unable to find such a reference, the linker reports an error.
  • If such a reference is resolved, a section that is reachable from an entry point by at least one non-weak reference is marked as used. This ensures the section is not removed by the linker as an unused section. Each non-weak reference must be resolved by exactly one definition. If there are multiple definitions, the linker reports an error.
Symbols can be given weak binding by the compiler and assembler.
The linker does not load an object from a library to resolve a weak reference. It is able to resolve the weak reference only if the definition is included in the image for other reasons. The weak reference does not cause the linker to mark the section containing the definition as used, so it might be removed by the linker as unused. The definition might already exist in the image for several reasons:
  • The symbol has a non-weak reference from somewhere else in the code.
  • The symbol definition exists in the same ELF section as a symbol definition that is included for any of these reasons.
  • The symbol definition is in a section that has been specified using --keep, or contains an ENTRY point.
  • The symbol definition is in an object file included in the link and the --no_remove option is used. The object file is not referenced from a library unless that object file within the library is explicitly included on the linker command-line.
In summary, a weak reference is resolved if the definition is already included in the image, but it does not determine if that definition is included.
An unresolved weak function call is replaced with either:
  • A no-operation instruction, NOP.
  • A branch with link instruction, BL, to the following instruction. That is, the function call just does not happen.
Weak definitions
A function definition, or an exported label in assembler, can also be marked as weak, as can a variable definition. In this case, a weak symbol definition is created in the object file.
You can use a weak definition to resolve any reference to that symbol in the same way as a normal definition. However, if another non-weak definition of that symbol exists in the build, the linker uses that definition instead of the weak definition, and does not produce an error due to multiply-defined symbols.

Example of a weak reference

A library contains a function foo(), that is called in some builds of an application but not in others. If it is used, init_foo() must be called first. You can use weak references to automate the call to init_foo().
The library can define init_foo() and foo() in the same ELF section. The application initialization code must call init_foo() weakly. If the application includes foo() for any reason, it also includes init_foo() and this is called from the initialization code. In any builds that do not include foo(), the call to init_foo() is removed by the linker.
Typically, the code for multiple functions defined within a single source file is placed into a single ELF section by the compiler. However, certain build options might alter this behavior, so you must use them with caution if your build is relying on the grouping of files into ELF sections:
  • The compiler command-line option --split_sections results in each function being placed in its own section. In this example, compiling the library with this option results in foo() and init_foo() being placed in separate sections. Therefore init_foo() is not automatically included in the build due to a call to foo().
  • The linker feedback mechanism, --feedback, records init_foo() as being unused during the link step. This causes the compiler to place init_foo() into its own section during subsequent compilations, so that it can be removed.
  • The compiler directive #pragma arm section also instructs the compiler to generate a separate ELF section for some functions.
In this example, there is no need to rebuild the initialization code between builds that include foo() and do not include foo(). There is also no possibility of accidentally building an application with a version of the initialization code that does not call init_foo(), and other parts of the application that call foo().
An example of foo.c source code that is typically built into a library is:
void init_foo()
    // Some initialization code
void foo()
     // A function that is included in some builds
     // and requires init_foo() to be called first.
An example of init.c is:
__weak void init_foo(void);
int main(void)
    //  Rest of code that may make calls to foo() directly or indirectly.
An example of a weak reference generated by the assembler is:
  IMPORT init_foo WEAK
  AREA init, CODE, readonly
    BL init_foo
    ;Rest of code

Example of a weak definition

A simple or dummy implementation of a function can be provided as a weak definition. This enables you to build software with defined behavior without having to provide a full implementation of the function. It also enables you to provide a full implementation for some builds if required.
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.