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