|
295
|
1 LWLINK linker scripts
|
|
|
2
|
|
|
3 A linker script is used to instruct the linker about how to assemble the
|
|
|
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
|
|
|
6 section not referenced by a directive is assumed to be loaded after the
|
|
|
7 final section explicitly referenced.
|
|
|
8
|
|
304
|
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
|
|
295
|
15 A section may only be referenced once. Any subsequent references will have
|
|
|
16 no effect.
|
|
|
17
|
|
304
|
18 All numbers are hexadecimal.
|
|
|
19
|
|
|
20 section <name> load <addr>
|
|
295
|
21
|
|
|
22 This causes the section <name> to load at <addr>. For raw target, only one
|
|
|
23 "load at" entry is allowed for non-bss sections and it must be the first
|
|
|
24 one. For raw targets, it affects the addresses the linker assigns to symbols
|
|
|
25 but has no other affect on the output. bss sections may all have separate
|
|
|
26 load addresses but since they will not appear in the binary anyway, this is
|
|
|
27 okay.
|
|
|
28
|
|
304
|
29 For the DECB target, each "load" entry will cause a new "block" to be
|
|
295
|
30 output to the binary which will contain the load address. It is legal for
|
|
|
31 sections to overlap in this manner - the linker assumes the loader will sort
|
|
|
32 everything out.
|
|
|
33
|
|
304
|
34 section <name>
|
|
|
35
|
|
|
36 This will cause the section <name> to load after the previously listed
|
|
|
37 section.
|
|
|
38
|
|
|
39 exec <addr or sym>
|
|
295
|
40
|
|
304
|
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.
|
|
295
|
49
|
|
304
|
50 pad <size>
|
|
295
|
51
|
|
|
52 This will cause the output file to be padded with NUL bytes to be exactly
|
|
|
53 <size> bytes in length. This only makes sense for a raw target.
|
|
|
54
|
|
|
55
|
|
|
56 If <name> is "*", then any section not already matched by the script will be
|
|
|
57 matched. For format *,<flags> can be used to select sections which have
|
|
|
58 particular flags set (or not set). For instance:
|
|
|
59
|
|
|
60 *,!bss This would match all sections that do not have the bss flag set
|
|
|
61 *,bss this would match all sections that do have the bss flag set
|
|
|
62
|
|
|
63
|
