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