Commit | Line | Data |
---|---|---|
d611a82e KK |
1 | # A PE linker script for PowerPC. |
2 | # Loosely based on Steve Chamberlain's pe.sc. | |
3 | # All new mistakes should be credited to Kim Knuttila (krk@cygnus.com) | |
4 | # | |
5 | # These are substituted in as variables in order to get '}' in a shell | |
6 | # conditional expansion. | |
7 | INIT='.init : { *(.init) }' | |
8 | FINI='.fini : { *(.fini) }' | |
9 | cat <<EOF | |
10 | OUTPUT_FORMAT(${OUTPUT_FORMAT}) | |
11 | ${LIB_SEARCH_DIRS} | |
12 | ||
13 | /* Much of this layout was determined by delving into .exe files for | |
14 | the box generated by other compilers/linkers/etc. This means that | |
15 | if a particular feature did not happen to appear in one of the | |
16 | subject files, then it may not be yet supported. | |
17 | */ | |
18 | ||
19 | /* It's "mainCRTStartup", not "_mainCRTStartup", and it's located in | |
20 | one of the two .lib files (libc.lib and kernel32.lib) that currently | |
21 | must be present on the link line. This means that you must use | |
22 | "-u mainCRTStartup" to make sure it gets included in the link. | |
23 | */ | |
24 | ||
25 | ENTRY(mainCRTStartup) | |
26 | ||
27 | SECTIONS | |
28 | { | |
29 | ||
30 | /* text - the usual meaning */ | |
31 | .text ${RELOCATING+ __image_base__ + __section_alignment__ } : | |
32 | { | |
33 | ${RELOCATING+ *(.init);} | |
34 | *(.text) | |
35 | ${CONSTRUCTING+ ___CTOR_LIST__ = .; __CTOR_LIST__ = . ; | |
36 | LONG (-1); *(.ctors); *(.ctor); LONG (0); } | |
37 | ${CONSTRUCTING+ ___DTOR_LIST__ = .; __DTOR_LIST__ = . ; | |
38 | LONG (-1); *(.dtors); *(.dtor); LONG (0); } | |
39 | ${RELOCATING+ *(.fini);} | |
40 | ${RELOCATING+ etext = .}; | |
41 | } | |
42 | ||
43 | /* rdata - Read Only Runtime Data | |
44 | CTR sections: All of the CRT (read only C runtime data) sections | |
45 | appear at the start of the .rdata (read only runtime data) | |
46 | section, in the following order. Don't know if it matters or not. | |
47 | Not all sections are always present either. | |
48 | .rdata: compiler generated read only data | |
49 | .xdata: compiler generated exception handling table. (Most docs | |
50 | seem to suggest that this section is now deprecated infavor | |
51 | of the ydata section) | |
52 | .edata: The exported names table. | |
53 | */ | |
54 | .rdata BLOCK(__section_alignment__) : | |
55 | { | |
56 | *(.CRT\$XCA); | |
57 | *(.CRT\$XCC); | |
58 | *(.CRT\$XCZ); | |
59 | *(.CRT\$XIA); | |
60 | *(.CRT\$XIC); | |
61 | *(.CRT\$XIZ); | |
62 | *(.CRT\$XLA); | |
63 | *(.CRT\$XLZ); | |
64 | *(.CRT\$XPA); | |
65 | *(.CRT\$XPX); | |
66 | *(.CRT\$XPZ); | |
67 | *(.CRT\$XTA); | |
68 | *(.CRT\$XTZ); | |
69 | *(.rdata); | |
70 | *(.xdata); | |
71 | } | |
72 | ||
73 | .edata BLOCK(__section_alignment__) : | |
74 | { | |
75 | *(.edata); | |
76 | } | |
77 | ||
78 | /* data - initialized data | |
79 | .ydata: exception handling information. | |
80 | .data: the usual meaning. | |
81 | .data2: more of the same. | |
82 | .bss: For some reason, bss appears to be included in the data | |
83 | section, as opposed to being given a section of it's own. | |
84 | COMMON: | |
85 | */ | |
86 | .data BLOCK(__section_alignment__) : | |
87 | { | |
88 | __data_start__ = . ; | |
89 | *(.ydata); | |
90 | *(.data); | |
91 | *(.data2); | |
92 | __bss_start__ = . ; | |
93 | *(.bss) ; | |
94 | *(COMMON); | |
95 | __bss_end__ = . ; | |
96 | ${RELOCATING+ end = .}; | |
97 | __data_end__ = . ; | |
98 | } | |
99 | ||
100 | /* The exception handling table. A sequence of 5 word entries. Section | |
101 | address and extent are placed in the DataDirectory. | |
102 | */ | |
103 | .pdata BLOCK(__section_alignment__) : | |
104 | { | |
105 | *(.pdata) | |
106 | ; | |
107 | } | |
108 | ||
109 | /* The idata section is chock full of magic bits. | |
110 | 1. Boundaries around various idata parts are used to initialize | |
111 | some of the fields of the DataDirectory. In particular, the | |
112 | magic for 2, 4 and 5 are known to be used. Some compilers | |
113 | appear to generate magic section symbols for this purpose. | |
114 | Where we can, we catch such symbols and use our own. This of | |
115 | course is something less than a perfect strategy. | |
116 | 2. The table of contents is placed immediately after idata4. | |
117 | The ".private.toc" sections are generated by the ppc bfd. The | |
118 | .toc variable is generated by gas, and resolved here. It is | |
119 | used to initialized function descriptors (and anyone else who | |
120 | needs the address of the module's toc). The only thing | |
121 | interesting about it at all? Most ppc instructions using it | |
122 | have a 16bit displacement field. The convention for addressing | |
123 | is to initialize the .toc value to 32K past the start of the | |
124 | actual toc, and subtract 32K from all references, thus using | |
125 | the entire 64K range. Naturally, the reloc code must agree | |
126 | on this number or you get pretty stupid results. | |
127 | */ | |
128 | .idata BLOCK(__section_alignment__) : | |
129 | { | |
130 | __idata2_magic__ = .; | |
131 | *(.idata\$2); | |
132 | __idata3_magic__ = .; | |
133 | *(.idata\$3); | |
134 | __idata4_magic__ = .; | |
135 | *(.idata\$4); | |
136 | .toc = . + 32768; | |
137 | *(.private.toc); | |
138 | __idata5_magic__ = .; | |
139 | *(.idata\$5); | |
140 | __idata6_magic__ = .; | |
141 | *(.idata\$6); | |
142 | __idata7_magic__ = .; | |
143 | *(.idata\$7); | |
144 | ; | |
145 | } | |
146 | ||
147 | /* reldata -- data that requires relocation | |
148 | */ | |
149 | .reldata BLOCK(__section_alignment__) : | |
150 | { | |
151 | *(.reldata) | |
152 | ; | |
153 | } | |
154 | ||
155 | /* We don't do anything useful with codeview debugger support or the | |
156 | directive section (yet). Hopefully, we junk them correctly. | |
157 | */ | |
158 | .junk BLOCK(__section_alignment__) : | |
159 | { | |
160 | *(.debug\$S) | |
161 | *(.debug\$T) | |
162 | *(.debug\$F) | |
163 | *(.drectve) | |
164 | ; | |
165 | } | |
166 | ||
167 | /* Resources */ | |
168 | .rsrc BLOCK(__section_alignment__) : | |
169 | { | |
170 | *(.rsrc\$01) | |
171 | *(.rsrc\$02) | |
172 | ; | |
173 | } | |
174 | ||
175 | /* The .reloc section is currently generated by the dlltool from Steve | |
176 | Chamberlain in a second pass of linking. Section address and extent | |
177 | are placed in the DataDirectory. | |
178 | */ | |
179 | .reloc BLOCK(__section_alignment__) : | |
180 | { | |
181 | *(.reloc) | |
182 | ; | |
183 | } | |
184 | ||
185 | .stab BLOCK(__section_alignment__) ${RELOCATING+(NOLOAD)} : | |
186 | { | |
187 | [ .stab ] | |
188 | } | |
189 | ||
190 | .stabstr BLOCK(__section_alignment__) ${RELOCATING+(NOLOAD)} : | |
191 | { | |
192 | [ .stabstr ] | |
193 | } | |
194 | } | |
195 | EOF |