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