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