comparison doc/scripts.txt @ 304:9c6462b3a288

Documented the "exec" directive in linker scripts
author lost
date Thu, 22 Jan 2009 02:05:30 +0000
parents 7a3d66e72a4c
children
comparison
equal deleted inserted replaced
303:13272197d278 304:9c6462b3a288
4 various sections into a completed binary. It consists of a series of 4 various sections into a completed binary. It consists of a series of
5 directives which are considered in the order they are encountered. Any 5 directives which are considered in the order they are encountered. Any
6 section not referenced by a directive is assumed to be loaded after the 6 section not referenced by a directive is assumed to be loaded after the
7 final section explicitly referenced. 7 final section explicitly referenced.
8 8
9 The sections will appear in the resulting binary in the order they are
10 specified in the script file.
11
12 If a referenced section is not found, the linker will behave as though the
13 section did exist but had a zero size, no relocations, and no exports.
14
9 A section may only be referenced once. Any subsequent references will have 15 A section may only be referenced once. Any subsequent references will have
10 no effect. 16 no effect.
11 17
12 section <name> load at <addr> 18 All numbers are hexadecimal.
19
20 section <name> load <addr>
13 21
14 This causes the section <name> to load at <addr>. For raw target, only one 22 This causes the section <name> to load at <addr>. For raw target, only one
15 "load at" entry is allowed for non-bss sections and it must be the first 23 "load at" entry is allowed for non-bss sections and it must be the first
16 one. For raw targets, it affects the addresses the linker assigns to symbols 24 one. For raw targets, it affects the addresses the linker assigns to symbols
17 but has no other affect on the output. bss sections may all have separate 25 but has no other affect on the output. bss sections may all have separate
18 load addresses but since they will not appear in the binary anyway, this is 26 load addresses but since they will not appear in the binary anyway, this is
19 okay. 27 okay.
20 28
21 For the DECB target, each "load at" entry will cause a new "block" to be 29 For the DECB target, each "load" entry will cause a new "block" to be
22 output to the binary which will contain the load address. It is legal for 30 output to the binary which will contain the load address. It is legal for
23 sections to overlap in this manner - the linker assumes the loader will sort 31 sections to overlap in this manner - the linker assumes the loader will sort
24 everything out. 32 everything out.
25 33
26 section <name> load after <name2> 34 section <name>
27 35
28 This will cause the section <name> to load after <name2>. This has the 36 This will cause the section <name> to load after the previously listed
29 effect of essentially gluing <name> onto the end of <name2>. If multiple 37 section.
30 sections are specified to load after a particular section, they will load in
31 the order specified.
32 38
33 pad to <size> 39 exec <addr or sym>
40
41 This will cause the execution address (entry point) to be the address
42 specified (in hex) *or* the specified symbol name. The symbol name must
43 match a symbol that is exported by one of the object files being linked.
44 This has no effect for targets that do not encode the entry point into the
45 resulting file. If not specified, the entry point is assumed to be address 0
46 which is probably not what you want. The default link scripts for targets
47 that support this directive automatically starts at the beginning of the
48 first section (usually "init" or "code") that is emitted in the binary.
49
50 pad <size>
34 51
35 This will cause the output file to be padded with NUL bytes to be exactly 52 This will cause the output file to be padded with NUL bytes to be exactly
36 <size> bytes in length. This only makes sense for a raw target. 53 <size> bytes in length. This only makes sense for a raw target.
37 54
38 55