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