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