ARM Compiler toolchain Using the Linker - ARM Information Center

More documents

Recommendations

Info

Image structure and generation 4.21 Using command-line options to control the generation of C++ exception tables 4.21.1 See also By default, or if the option --exceptions is specified, the image can contain exception tables. Exception tables are discarded silently if no code throws an exception. However, if the option --no_exceptions is specified, the linker generates an error if any exceptions sections are present after unused sections have been eliminated. You can use the --no_exceptions option to ensure that your code is exceptions free. The linker generates an error message to highlight that exceptions have been found and does not produce a final image. However, you can use the --no_exceptions option with the --diag_warning option to downgrade the error message to a warning. The linker produces a final image but also generates a message to warn you that exceptions have been found. The linker can create exception tables for legacy objects that contain debug frame information. The linker can do this safely for C and assembly language objects. By default, the linker does not create exception tables. This is the same as using the linker option --exceptions_tables=nocreate. The linker option --exceptions_tables=unwind enables the linker to use the .debug_frame information to create a register-restoring unwinding table for each section in your image that does not already have an exception table. If this is not possible, the linker creates a nounwind table instead. Use the linker option --exceptions_tables=cantunwind to create a nounwind table for each section in your image that does not already have an exception table. Note Be aware of the following: • With the default settings, that is, --exceptions --exception_tables=nocreate, it is not safe to throw an exception through C or assembly code, unless the C code is compiled with the option --exceptions. • The linker can generate frame unwinding instructions from objects with .debug_frame information. Frame unwinding is sufficient for C and assembler code. It is not sufficient for C++ code, because it does not call the destructors for the objects on the stack that is being unwound. The cleanup code for C++ must be generated by the compiler with the --exceptions option. Reference Linker Reference: • --diag_warning=tag[,tag,...] on page 2-48 • --exceptions, --no_exceptions on page 2-61 • --exceptions_tables=action on page 2-62. Compiler Reference: • --exceptions, --no_exceptions on page 3-85. ARM DUI 0474C Copyright © 2010-2011 ARM. All rights reserved. 4-31 ID080411 Non-Confidential
4.22 About weak references and definitions Image structure and generation Weak references and definitions provide additional flexibility in the way the linker includes various functions and variables in a build. These references are typically to library functions. Weak references If the linker cannot resolve normal, non-weak, references to symbols included in the link, 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, the section it is resolved to 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. Function or variable declarations in C source files can be marked with the __weak qualifier. As with extern, this qualifier tells the compiler that a function or variable is declared in another source file. Because the definition of this function or variable might not be available to the compiler, it creates a weak reference to be resolved by the linker. 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 is strongly referenced 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. A weak definition can be used 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. ARM DUI 0474C Copyright © 2010-2011 ARM. All rights reserved. 4-32 ID080411 Non-Confidential
Page 1 and 2:
® ARM Copyright © 2010-2011 ARM.
Page 3 and 4:
Contents ARM Compiler toolchain Usi
Page 5 and 6:
Contents 7.15 Creating a symdefs fi
Page 7 and 8:
Chapter 1 Conventions and feedback
Page 9 and 10: Chapter 2 Overview of the linker Th
Page 11 and 12: Concepts • Demand paging on page
Page 13 and 14: 2.3 Linker command-line options lis
Page 15 and 16: • --keep_protected_symbols on pag
Page 17 and 18: • --eager_load_debug, --no_eager_
Page 19 and 20: 2.5 What the linker outputs 2.5.1 S
Page 21 and 22: Chapter 3 Linking models supported
Page 23 and 24: 3.2 Bare-metal linking model 3.2.1
Page 25 and 26: Linking models supported by armlink
Page 27 and 28: 3.5.1 See also • There are restri
Page 29 and 30: 3.7 Concepts common to both BPABI a
Page 31 and 32: Image structure and generation •
Page 33 and 34: 4.1.1 See also Image structure and
Page 35 and 36: 4.3 Load view and execution view of
Page 37 and 38: 4.4 Methods of specifying an image
Page 39 and 40: 4.5 Types of simple image 4.5.1 See
Page 47 and 48: 4.10 About specifying an initial en
Page 49 and 50: 4.11.2 Example 4.11.3 See also The
Page 51 and 52: 4.13 Section alignment with the lin
Page 53 and 54: Reference Linker Reference: • --a
Page 55 and 56: 4.16 Overview of veneers 4.16.1 See
Page 57 and 58: 4.18 Veneer types 4.18.1 See also I
Page 59: 4.20 Reuse of veneers when scatter-
Page 63 and 64: BL init_foo ;Rest of code END 4.22.
Page 65 and 66: Image structure and generation 4.24
Page 67 and 68: 4.25 Specifying user libraries when
Page 69 and 70: 4.27 Use of the strict family of op
Page 71 and 72: 5.1 Elimination of common debug sec
Page 73 and 74: 5.3 Elimination of unused sections
Page 75 and 76: 5.4 Elimination of unused virtual f
Page 77 and 78: • --scatter=file on page 2-142. C
Page 79 and 80: 5.6.1 See also Using linker optimiz
Page 81 and 82: 3. Creates the output image. 5.7.3
Page 83 and 84: 5.9 How the linker chooses a compre
Page 85 and 86: 5.11 How compression is applied 5.1
Page 87 and 88: 5.13 Inlining functions with the li
Page 89 and 90: Reference Assembler Reference: •
Page 91 and 92: 5.16 About reordering of tail calli
Page 93 and 94: 5.18 About merging comment sections
Page 95 and 96: 6.1 Linker options for getting info
Page 97 and 98: 6.3 Example of using the --info lin
Page 99 and 100: 6.4 How to find where a symbol is p
Page 101 and 102: • Load$$LR$$ load region symbols
Page 103 and 104: 7.2 Accessing linker-defined symbol
Page 105 and 106: 7.4 Image$$ execution region symbol
Page 107 and 108: 7.5.1 See also Accessing and managi
Page 109 and 110: 7.7 Region name values when not sca
Page 111 and 112:
7.9 Importing linker-defined symbol
Page 113 and 114:
7.11 Section-related symbols 7.11.1
Page 115 and 116:
7.13 Input section symbols 7.13.1 S
Page 117 and 118:
7.15 Creating a symdefs file 7.15.1
Page 119 and 120:
7.17 Reading a symdefs file 7.17.1
Page 121 and 122:
7.18.2 See also 0x0000814D T __argv
Page 123 and 124:
7.20 Specifying steering files on t
Page 125 and 126:
7.22 Steering file format 7.22.1 Se
Page 127 and 128:
7.24 Using $Super$$ and $Sub$$ to p
Page 129 and 130:
Using scatter files • Images with
Page 131 and 132:
8.2 When to use scatter-loading 8.2
Page 133 and 134:
• --startup=symbol, --no_startup
Page 135 and 136:
8.4.1 See also Concepts • About s
Page 137 and 138:
8.5.1 See also } SRAM 0x8000 0x8000
Page 139 and 140:
8.7 Specifying stack and heap using
Page 141 and 142:
8.9 Creating root execution regions
Page 143 and 144:
8.9.2 See also Tasks • Using the
Page 145 and 146:
8.11 Placing functions and data at
Page 147 and 148:
Using scatter files RAM 0x200000 (0
Page 149 and 150:
Using scatter files • Using __at
Page 151 and 152:
Developing Software for ARM ® Proc
Page 153 and 154:
} } .ANY1(+RO) ; evenly distributed
Page 155 and 156:
8.14 Examples of using placement al
Page 157 and 158:
Using scatter files 8.15 Example of
Page 159 and 160:
8.16 Examples of using sorting algo
Page 161 and 162:
8.17 Selecting veneer input section
Page 163 and 164:
Compiler Reference: • __attribute
Page 165 and 166:
8.20 Restrictions on placing __at s
Page 167 and 168:
8.21.1 See also Using scatter files
Page 169 and 170:
8.23 Placing a key in flash memory
Page 171 and 172:
8.25 Placement of sections with ove
Page 173 and 174:
8.25.1 See also Using scatter files
Page 175 and 176:
8.27 Example of placing code in a r
Page 177 and 178:
8.29 Example of placing ARM C++ lib
Page 179 and 180:
8.31 Reserving an empty region Usin
Page 181 and 182:
8.32 About creating regions on page
Page 183 and 184:
8.33 Overalignment of execution reg
Page 185 and 186:
8.35 Expression evaluation in scatt
Page 187 and 188:
8.37 Equivalent scatter-loading des
Page 189 and 190:
Using scatter files Example 8-23 Po
Page 191 and 192:
Using scatter files Example 8-25 Po
Page 193 and 194:
Using scatter files • The ER_ZI e
Page 195 and 196:
Using scatter files Example 8-29 Sc
Page 197 and 198:
Chapter 9 GNU ld script support in
Page 199 and 200:
9.2 Typical use cases for using ld
Page 201 and 202:
Reference Linker Reference: • --l
Page 203 and 204:
9.5 Recommendations for using ld sc
Page 205 and 206:
.data : { __data_start = .; *(.data
Page 207 and 208:
9.6.4 See also .got 0 : { *(.got.pl
Page 209 and 210:
9.7.1 See also } .dynamic : { *(.dy
Page 211 and 212:
9.8.1 See also { *(.bss .bss.*) . =
Page 213 and 214:
Chapter 10 BPABI and SysV shared li
Page 215 and 216:
BPABI and SysV shared libraries and
Page 217 and 218:
10.3 Concepts common to all BPABI m
Page 219 and 220:
10.5 Symbol visibility for BPABI mo
Page 221 and 222:
10.6 Automatic import and export fo
Page 223 and 224:
10.8 Symbol versioning for BPABI mo
Page 225 and 226:
10.10 Linker options for SysV model
Page 227 and 228:
Page 229 and 230:
10.13 Addressing modes in the SysV
Page 231 and 232:
Page 233 and 234:
10.17 Linker options for bare metal
Page 235 and 236:
Page 237 and 238:
10.21 Addressing modes in the BPABI
Page 239 and 240:
10.23 About symbol versioning 10.23
Page 241 and 242:
10.25 Example of creating versioned
Page 243 and 244:
10.27 Linker options for enabling i
Page 245 and 246:
Chapter 11 Features of the Base Pla
Page 247 and 248:
Features of the Base Platform linki
Page 249 and 250:
11.2 Example scatter file for the B
Page 251 and 252:
Features of the Base Platform linki
Page 253:
Change Topics affected Revisions fo
show all

ARM Compiler toolchain Using the Linker - ARM Information Center

Create successful ePaper yourself

Delete template?

Save as template?