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
|
---|