[489740f] | 1 | .. comment SPDX-License-Identifier: CC-BY-SA-4.0 |
---|
| 2 | |
---|
[6d7a4d2] | 3 | |
---|
| 4 | .. COMMENT: COPYRIGHT (c) 1988-2011. |
---|
| 5 | .. COMMENT: On-Line Applications Research Corporation (OAR). |
---|
| 6 | .. COMMENT: All rights reserved. |
---|
| 7 | |
---|
[b350509] | 8 | Linker Script |
---|
| 9 | ############# |
---|
| 10 | |
---|
| 11 | What is a "linkcmds" file? |
---|
| 12 | ========================== |
---|
| 13 | |
---|
| 14 | The ``linkcmds`` file is a script which is passed to the linker at linking |
---|
[6d7a4d2] | 15 | time. This file describes the memory configuration of the board as needed to |
---|
| 16 | link the program. Specifically it specifies where the code and data for the |
---|
| 17 | application will reside in memory. |
---|
[b350509] | 18 | |
---|
[6d7a4d2] | 19 | The format of the linker script is defined by the GNU Loader ``ld`` which is |
---|
| 20 | included as a component of the GNU Binary Utilities. If you are using |
---|
| 21 | GNU/Linux, then you probably have the documentation installed already and are |
---|
| 22 | using these same tools configured for *native* use. Please visit the Binutils |
---|
| 23 | project http://sourceware.org/binutils/ if you need more information. |
---|
[b350509] | 24 | |
---|
| 25 | Program Sections |
---|
| 26 | ================ |
---|
| 27 | |
---|
[6d7a4d2] | 28 | An embedded systems programmer must be much more aware of the placement of |
---|
| 29 | their executable image in memory than the average applications programmer. A |
---|
| 30 | program destined to be embedded as well as the target system have some specific |
---|
| 31 | properties that must be taken into account. Embedded machines often mean |
---|
| 32 | average performances and small memory usage. It is the memory usage that |
---|
| 33 | concerns us when examining the linker command file. |
---|
[b350509] | 34 | |
---|
| 35 | Two types of memories have to be distinguished: |
---|
| 36 | |
---|
| 37 | - RAM - volatile offering read and write access |
---|
| 38 | |
---|
| 39 | - ROM - non-volatile but read only |
---|
| 40 | |
---|
[6d7a4d2] | 41 | Even though RAM and ROM can be found in every personal computer, one generally |
---|
| 42 | doesn't care about them. In a personal computer, a program is nearly always |
---|
| 43 | stored on disk and executed in RAM. Things are a bit different for embedded |
---|
| 44 | targets: the target will execute the program each time it is rebooted or |
---|
| 45 | switched on. The application program is stored in non-volatile memory such as |
---|
| 46 | ROM, PROM, EEPROM, or Flash. On the other hand, data processing occurs in RAM. |
---|
| 47 | |
---|
| 48 | This leads us to the structure of an embedded program. In rough terms, an |
---|
| 49 | embedded program is made of sections. It is the responsibility of the |
---|
| 50 | application programmer to place these sections in the appropriate place in |
---|
| 51 | target memory. To make this clearer, if using the COFF object file format on |
---|
| 52 | the Motorola m68k family of microprocessors, the following sections will be |
---|
| 53 | present: |
---|
| 54 | |
---|
| 55 | - code (``.text``) section: |
---|
| 56 | is the program's code and it should not be modified. This section may be |
---|
| 57 | placed in ROM. |
---|
| 58 | |
---|
| 59 | - non-initialized data (``.bss``) section: |
---|
[b350509] | 60 | holds uninitialized variables of the program. It can stay in RAM. |
---|
| 61 | |
---|
[6d7a4d2] | 62 | - initialized data (``.data``) section: |
---|
| 63 | holds the initialized program data which may be modified during the program's |
---|
| 64 | life. This means they have to be in RAM. On the other hand, these variables |
---|
| 65 | must be set to predefined values, and those predefined values have to be |
---|
| 66 | stored in ROM. |
---|
| 67 | |
---|
| 68 | .. note:: |
---|
[b350509] | 69 | |
---|
[6d7a4d2] | 70 | Many programs and support libraries unknowingly assume that the ``.bss`` |
---|
| 71 | section and, possibly, the application heap are initialized to zero at |
---|
| 72 | program start. This is not required by the ISO/ANSI C Standard but is such |
---|
| 73 | a common requirement that most BSPs do this. |
---|
[b350509] | 74 | |
---|
[6d7a4d2] | 75 | That brings us up to the notion of the image of an executable: it consists of |
---|
| 76 | the set of the sections that together constitute the application. |
---|
[b350509] | 77 | |
---|
| 78 | Image of an Executable |
---|
| 79 | ====================== |
---|
| 80 | |
---|
[6d7a4d2] | 81 | As a program executable has many sections (note that the user can define their |
---|
| 82 | own, and that compilers define theirs without any notice), one has to specify |
---|
| 83 | the placement of each section as well as the type of memory (RAM or ROM) the |
---|
| 84 | sections will be placed into. For instance, a program compiled for a Personal |
---|
| 85 | Computer will see all the sections to go to RAM, while a program destined to be |
---|
| 86 | embedded will see some of his sections going into the ROM. |
---|
| 87 | |
---|
| 88 | The connection between a section and where that section is loaded into memory |
---|
| 89 | is made at link time. One has to let the linker know where the different |
---|
| 90 | sections are to be placed once they are in memory. |
---|
[b350509] | 91 | |
---|
[6d7a4d2] | 92 | The following example shows a simple layout of program sections. With some |
---|
| 93 | object formats, there are many more sections but the basic layout is |
---|
| 94 | conceptually similar. |
---|
| 95 | |
---|
| 96 | ============ ============= |
---|
| 97 | .text RAM or ROM |
---|
| 98 | .data RAM |
---|
| 99 | .bss RAM |
---|
| 100 | ============ ============= |
---|
[b350509] | 101 | |
---|
| 102 | Example Linker Command Script |
---|
| 103 | ============================= |
---|
| 104 | |
---|
| 105 | The GNU linker has a command language to specify the image format. This |
---|
[6d7a4d2] | 106 | command language can be quite complicated but most of what is required can be |
---|
| 107 | learned by careful examination of a well-documented example. The following is |
---|
| 108 | a heavily commented version of the linker script used with the the ``gen68340`` |
---|
| 109 | BSP This file can be found at $BSP340_ROOT/startup/linkcmds. |
---|
| 110 | |
---|
[f29b7c1c] | 111 | .. code-block:: c |
---|
[b350509] | 112 | |
---|
| 113 | /* |
---|
[6d7a4d2] | 114 | * Specify that the output is to be coff-m68k regardless of what the |
---|
| 115 | * native object format is. |
---|
| 116 | */ |
---|
[b350509] | 117 | OUTPUT_FORMAT(coff-m68k) |
---|
| 118 | /* |
---|
[6d7a4d2] | 119 | * Set the amount of RAM on the target board. |
---|
| 120 | * |
---|
| 121 | * NOTE: The default may be overridden by passing an argument to ld. |
---|
| 122 | */ |
---|
[b350509] | 123 | RamSize = DEFINED(RamSize) ? RamSize : 4M; |
---|
| 124 | /* |
---|
[6d7a4d2] | 125 | * Set the amount of RAM to be used for the application heap. Objects |
---|
| 126 | * allocated using malloc() come from this area. Having a tight heap |
---|
| 127 | * size is somewhat difficult and multiple attempts to squeeze it may |
---|
| 128 | * be needed reducing memory usage is important. If all objects are |
---|
| 129 | * allocated from the heap at system initialization time, this eases |
---|
| 130 | * the sizing of the application heap. |
---|
| 131 | * |
---|
| 132 | * NOTE 1: The default may be overridden by passing an argument to ld. |
---|
| 133 | * |
---|
| 134 | * NOTE 2: The TCP/IP stack requires additional memory in the Heap. |
---|
| 135 | * |
---|
| 136 | * NOTE 3: The GNAT/RTEMS run-time requires additional memory in |
---|
| 137 | * the Heap. |
---|
| 138 | */ |
---|
[b350509] | 139 | HeapSize = DEFINED(HeapSize) ? HeapSize : 0x10000; |
---|
| 140 | /* |
---|
[6d7a4d2] | 141 | * Set the size of the starting stack used during BSP initialization |
---|
| 142 | * until first task switch. After that point, task stacks allocated |
---|
| 143 | * by RTEMS are used. |
---|
| 144 | * |
---|
| 145 | * NOTE: The default may be overridden by passing an argument to ld. |
---|
| 146 | */ |
---|
[b350509] | 147 | StackSize = DEFINED(StackSize) ? StackSize : 0x1000; |
---|
| 148 | /* |
---|
[6d7a4d2] | 149 | * Starting addresses and length of RAM and ROM. |
---|
| 150 | * |
---|
| 151 | * The addresses must be valid addresses on the board. The |
---|
| 152 | * Chip Selects should be initialized such that the code addresses |
---|
| 153 | * are valid. |
---|
| 154 | */ |
---|
[b350509] | 155 | MEMORY { |
---|
| 156 | ram : ORIGIN = 0x10000000, LENGTH = 4M |
---|
| 157 | rom : ORIGIN = 0x01000000, LENGTH = 4M |
---|
| 158 | } |
---|
| 159 | /* |
---|
[6d7a4d2] | 160 | * This is for the network driver. See the Networking documentation |
---|
| 161 | * for more details. |
---|
| 162 | */ |
---|
[b350509] | 163 | ETHERNET_ADDRESS = |
---|
| 164 | DEFINED(ETHERNET_ADDRESS) ? ETHERNET_ADDRESS : 0xDEAD12; |
---|
| 165 | /* |
---|
[6d7a4d2] | 166 | * The following defines the order in which the sections should go. |
---|
| 167 | * It also defines a number of variables which can be used by the |
---|
| 168 | * application program. |
---|
| 169 | * |
---|
| 170 | * NOTE: Each variable appears with 1 or 2 leading underscores to |
---|
| 171 | * ensure that the variable is accessible from C code with a |
---|
| 172 | * single underscore. Some object formats automatically add |
---|
| 173 | * a leading underscore to all C global symbols. |
---|
| 174 | */ |
---|
[b350509] | 175 | SECTIONS { |
---|
| 176 | /* |
---|
[6d7a4d2] | 177 | * Make the RomBase variable available to the application. |
---|
| 178 | */ |
---|
[b350509] | 179 | _RamSize = RamSize; |
---|
| 180 | __RamSize = RamSize; |
---|
| 181 | /* |
---|
[6d7a4d2] | 182 | * Boot PROM - Set the RomBase variable to the start of the ROM. |
---|
| 183 | */ |
---|
[b350509] | 184 | rom : { |
---|
[6d7a4d2] | 185 | _RomBase = .; |
---|
| 186 | __RomBase = .; |
---|
[b350509] | 187 | } >rom |
---|
| 188 | /* |
---|
[6d7a4d2] | 189 | * Dynamic RAM - set the RamBase variable to the start of the RAM. |
---|
| 190 | */ |
---|
[b350509] | 191 | ram : { |
---|
[6d7a4d2] | 192 | _RamBase = .; |
---|
| 193 | __RamBase = .; |
---|
[b350509] | 194 | } >ram |
---|
| 195 | /* |
---|
[6d7a4d2] | 196 | * Text (code) goes into ROM |
---|
| 197 | */ |
---|
[b350509] | 198 | .text : { |
---|
[6d7a4d2] | 199 | /* |
---|
| 200 | * Create a symbol for each object (.o). |
---|
| 201 | */ |
---|
| 202 | CREATE_OBJECT_SYMBOLS |
---|
| 203 | /* |
---|
| 204 | * Put all the object files code sections here. |
---|
| 205 | */ |
---|
| 206 | *(.text) |
---|
| 207 | . = ALIGN (16); /* go to a 16-byte boundary */ |
---|
| 208 | /* |
---|
| 209 | * C++ constructors and destructors |
---|
| 210 | * |
---|
| 211 | * NOTE: See the CROSSGCC mailing-list FAQ for |
---|
| 212 | * more details about the "\[......]". |
---|
| 213 | */ |
---|
| 214 | __CTOR_LIST__ = .; |
---|
| 215 | [......] |
---|
| 216 | __DTOR_END__ = .; |
---|
| 217 | /* |
---|
| 218 | * Declares where the .text section ends. |
---|
| 219 | */ |
---|
| 220 | etext = .; |
---|
| 221 | _etext = .; |
---|
[b350509] | 222 | } >rom |
---|
| 223 | /* |
---|
[6d7a4d2] | 224 | * Exception Handler Frame section |
---|
| 225 | */ |
---|
[b350509] | 226 | .eh_fram : { |
---|
[6d7a4d2] | 227 | . = ALIGN (16); |
---|
| 228 | *(.eh_fram) |
---|
[b350509] | 229 | } >ram |
---|
| 230 | /* |
---|
[6d7a4d2] | 231 | * GCC Exception section |
---|
| 232 | */ |
---|
[b350509] | 233 | .gcc_exc : { |
---|
[6d7a4d2] | 234 | . = ALIGN (16); |
---|
| 235 | *(.gcc_exc) |
---|
[b350509] | 236 | } >ram |
---|
| 237 | /* |
---|
[6d7a4d2] | 238 | * Special variable to let application get to the dual-ported |
---|
| 239 | * memory. |
---|
| 240 | */ |
---|
[b350509] | 241 | dpram : { |
---|
[6d7a4d2] | 242 | m340 = .; |
---|
| 243 | _m340 = .; |
---|
| 244 | . += (8 * 1024); |
---|
[b350509] | 245 | } >ram |
---|
| 246 | /* |
---|
[6d7a4d2] | 247 | * Initialized Data section goes in RAM |
---|
| 248 | */ |
---|
[b350509] | 249 | .data : { |
---|
[6d7a4d2] | 250 | copy_start = .; |
---|
| 251 | *(.data) |
---|
| 252 | . = ALIGN (16); |
---|
| 253 | _edata = .; |
---|
| 254 | copy_end = .; |
---|
[b350509] | 255 | } >ram |
---|
| 256 | /* |
---|
[6d7a4d2] | 257 | * Uninitialized Data section goes in ROM |
---|
| 258 | */ |
---|
[b350509] | 259 | .bss : { |
---|
[6d7a4d2] | 260 | /* |
---|
| 261 | * M68K specific: Reserve some room for the Vector Table |
---|
| 262 | * (256 vectors of 4 bytes). |
---|
| 263 | */ |
---|
| 264 | M68Kvec = .; |
---|
| 265 | _M68Kvec = .; |
---|
| 266 | . += (256 * 4); |
---|
| 267 | /* |
---|
| 268 | * Start of memory to zero out at initialization time. |
---|
| 269 | */ |
---|
| 270 | clear_start = .; |
---|
| 271 | /* |
---|
| 272 | * Put all the object files uninitialized data sections |
---|
| 273 | * here. |
---|
| 274 | */ |
---|
| 275 | *(.bss) |
---|
| 276 | *(COMMON) |
---|
| 277 | . = ALIGN (16); |
---|
| 278 | _end = .; |
---|
| 279 | /* |
---|
| 280 | * Start of the Application Heap |
---|
| 281 | */ |
---|
| 282 | _HeapStart = .; |
---|
| 283 | __HeapStart = .; |
---|
| 284 | . += HeapSize; |
---|
| 285 | /* |
---|
| 286 | * The Starting Stack goes after the Application Heap. |
---|
| 287 | * M68K stack grows down so start at high address. |
---|
| 288 | */ |
---|
| 289 | . += StackSize; |
---|
| 290 | . = ALIGN (16); |
---|
| 291 | stack_init = .; |
---|
| 292 | clear_end = .; |
---|
| 293 | /* |
---|
| 294 | * The RTEMS Executive Workspace goes here. RTEMS |
---|
| 295 | * allocates tasks, stacks, semaphores, etc. from this |
---|
| 296 | * memory. |
---|
| 297 | */ |
---|
| 298 | _WorkspaceBase = .; |
---|
| 299 | __WorkspaceBase = .; |
---|
[b350509] | 300 | } >ram |
---|
| 301 | |
---|
| 302 | Initialized Data |
---|
| 303 | ================ |
---|
| 304 | |
---|
[6d7a4d2] | 305 | Now there's a problem with the initialized data: the ``.data`` section has to |
---|
| 306 | be in RAM as this data may be modified during the program execution. But how |
---|
| 307 | will the values be initialized at boot time? |
---|
[b350509] | 308 | |
---|
[6d7a4d2] | 309 | One approach is to place the entire program image in RAM and reload the image |
---|
| 310 | in its entirety each time the program is run. This is fine for use in a debug |
---|
| 311 | environment where a high-speed connection is available between the development |
---|
| 312 | host computer and the target. But even in this environment, it is cumbersome. |
---|
[b350509] | 313 | |
---|
[6d7a4d2] | 314 | The solution is to place a copy of the initialized data in a separate area of |
---|
| 315 | memory and copy it into the proper location each time the program is started. |
---|
| 316 | It is common practice to place a copy of the initialized ``.data`` section at |
---|
| 317 | the end of the code (``.text``) section in ROM when building a PROM image. The |
---|
| 318 | GNU tool ``objcopy`` can be used for this purpose. |
---|
[b350509] | 319 | |
---|
| 320 | The following figure illustrates the steps a linked program goes through |
---|
| 321 | to become a downloadable image. |
---|
| 322 | |
---|
[6d7a4d2] | 323 | +--------------+------+--------------------------+--------------------+ |
---|
| 324 | | .data (RAM) | | .data (RAM) | | |
---|
| 325 | +--------------+ +--------------------------+ | |
---|
| 326 | | .bss (RAM) | | .bss (RAM) | | |
---|
| 327 | +--------------+ +--------------------------+--------------------+ |
---|
| 328 | | .text (ROM) | | .text (ROM) | .text | |
---|
| 329 | +--------------+------+---------+----------+-----+--------------------+ |
---|
| 330 | | copy of .data (ROM) | | copy of .data | | |
---|
| 331 | +---------------------+---------+----------------+--------------------+ |
---|
| 332 | | Step 1 | Step 2 | Step 3 | |
---|
| 333 | +---------------------+--------------------------+--------------------+ |
---|
[b350509] | 334 | |
---|
| 335 | |
---|
| 336 | In Step 1, the program is linked together using the BSP linker script. |
---|
| 337 | |
---|
[6d7a4d2] | 338 | In Step 2, a copy is made of the ``.data`` section and placed after the |
---|
| 339 | ``.text`` section so it can be placed in PROM. This step is done after the |
---|
| 340 | linking time. There is an example of doing this in the file |
---|
| 341 | $RTEMS_ROOT/make/custom/gen68340.cfg: |
---|
| 342 | |
---|
| 343 | .. code-block:: shell |
---|
[b350509] | 344 | |
---|
| 345 | # make a PROM image using objcopy |
---|
[6d7a4d2] | 346 | m68k-rtems-objcopy --adjust-section-vma \ |
---|
| 347 | .data=`m68k-rtems-objdump --section-headers $(basename $@).exe | awk '[...]'` \ |
---|
[b350509] | 348 | $(basename $@).exe |
---|
| 349 | |
---|
[6d7a4d2] | 350 | .. note:: |
---|
[b350509] | 351 | |
---|
[6d7a4d2] | 352 | The address of the "copy of ``.data`` section" is created by extracting the |
---|
| 353 | last address in the ``.text`` section with an ``awk`` script. The details |
---|
| 354 | of how this is done are not relevant. |
---|
[b350509] | 355 | |
---|
[6d7a4d2] | 356 | Step 3 shows the final executable image as it logically appears in the target's |
---|
| 357 | non-volatile program memory. The board initialization code will copy the |
---|
| 358 | ""copy of ``.data`` section" (which are stored in ROM) to their reserved |
---|
| 359 | location in RAM. |
---|