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