Expose .edata section
This commit is contained in:
parent
781332facb
commit
d611a82e67
|
@ -1,3 +1,8 @@
|
|||
Thu Nov 30 13:14:30 1995 Kim Knuttila <krk@cygnus.com>
|
||||
|
||||
* scripttempl/ppcpe.sc: Moved .edata into its own section to
|
||||
expose it.
|
||||
|
||||
Thu Nov 30 11:32:34 1995 Manfred Hollstein KS/EF4A 60/1F/110 #40283 <manfred@lts.sel.alcatel.de>
|
||||
|
||||
* configure.host (m68*-motorola-sysv): Define HOSTING_CRT0 and
|
||||
|
|
|
@ -0,0 +1,195 @@
|
|||
# A PE linker script for PowerPC.
|
||||
# Loosely based on Steve Chamberlain's pe.sc.
|
||||
# All new mistakes should be credited to Kim Knuttila (krk@cygnus.com)
|
||||
#
|
||||
# These are substituted in as variables in order to get '}' in a shell
|
||||
# conditional expansion.
|
||||
INIT='.init : { *(.init) }'
|
||||
FINI='.fini : { *(.fini) }'
|
||||
cat <<EOF
|
||||
OUTPUT_FORMAT(${OUTPUT_FORMAT})
|
||||
${LIB_SEARCH_DIRS}
|
||||
|
||||
/* Much of this layout was determined by delving into .exe files for
|
||||
the box generated by other compilers/linkers/etc. This means that
|
||||
if a particular feature did not happen to appear in one of the
|
||||
subject files, then it may not be yet supported.
|
||||
*/
|
||||
|
||||
/* It's "mainCRTStartup", not "_mainCRTStartup", and it's located in
|
||||
one of the two .lib files (libc.lib and kernel32.lib) that currently
|
||||
must be present on the link line. This means that you must use
|
||||
"-u mainCRTStartup" to make sure it gets included in the link.
|
||||
*/
|
||||
|
||||
ENTRY(mainCRTStartup)
|
||||
|
||||
SECTIONS
|
||||
{
|
||||
|
||||
/* text - the usual meaning */
|
||||
.text ${RELOCATING+ __image_base__ + __section_alignment__ } :
|
||||
{
|
||||
${RELOCATING+ *(.init);}
|
||||
*(.text)
|
||||
${CONSTRUCTING+ ___CTOR_LIST__ = .; __CTOR_LIST__ = . ;
|
||||
LONG (-1); *(.ctors); *(.ctor); LONG (0); }
|
||||
${CONSTRUCTING+ ___DTOR_LIST__ = .; __DTOR_LIST__ = . ;
|
||||
LONG (-1); *(.dtors); *(.dtor); LONG (0); }
|
||||
${RELOCATING+ *(.fini);}
|
||||
${RELOCATING+ etext = .};
|
||||
}
|
||||
|
||||
/* rdata - Read Only Runtime Data
|
||||
CTR sections: All of the CRT (read only C runtime data) sections
|
||||
appear at the start of the .rdata (read only runtime data)
|
||||
section, in the following order. Don't know if it matters or not.
|
||||
Not all sections are always present either.
|
||||
.rdata: compiler generated read only data
|
||||
.xdata: compiler generated exception handling table. (Most docs
|
||||
seem to suggest that this section is now deprecated infavor
|
||||
of the ydata section)
|
||||
.edata: The exported names table.
|
||||
*/
|
||||
.rdata BLOCK(__section_alignment__) :
|
||||
{
|
||||
*(.CRT\$XCA);
|
||||
*(.CRT\$XCC);
|
||||
*(.CRT\$XCZ);
|
||||
*(.CRT\$XIA);
|
||||
*(.CRT\$XIC);
|
||||
*(.CRT\$XIZ);
|
||||
*(.CRT\$XLA);
|
||||
*(.CRT\$XLZ);
|
||||
*(.CRT\$XPA);
|
||||
*(.CRT\$XPX);
|
||||
*(.CRT\$XPZ);
|
||||
*(.CRT\$XTA);
|
||||
*(.CRT\$XTZ);
|
||||
*(.rdata);
|
||||
*(.xdata);
|
||||
}
|
||||
|
||||
.edata BLOCK(__section_alignment__) :
|
||||
{
|
||||
*(.edata);
|
||||
}
|
||||
|
||||
/* data - initialized data
|
||||
.ydata: exception handling information.
|
||||
.data: the usual meaning.
|
||||
.data2: more of the same.
|
||||
.bss: For some reason, bss appears to be included in the data
|
||||
section, as opposed to being given a section of it's own.
|
||||
COMMON:
|
||||
*/
|
||||
.data BLOCK(__section_alignment__) :
|
||||
{
|
||||
__data_start__ = . ;
|
||||
*(.ydata);
|
||||
*(.data);
|
||||
*(.data2);
|
||||
__bss_start__ = . ;
|
||||
*(.bss) ;
|
||||
*(COMMON);
|
||||
__bss_end__ = . ;
|
||||
${RELOCATING+ end = .};
|
||||
__data_end__ = . ;
|
||||
}
|
||||
|
||||
/* The exception handling table. A sequence of 5 word entries. Section
|
||||
address and extent are placed in the DataDirectory.
|
||||
*/
|
||||
.pdata BLOCK(__section_alignment__) :
|
||||
{
|
||||
*(.pdata)
|
||||
;
|
||||
}
|
||||
|
||||
/* The idata section is chock full of magic bits.
|
||||
1. Boundaries around various idata parts are used to initialize
|
||||
some of the fields of the DataDirectory. In particular, the
|
||||
magic for 2, 4 and 5 are known to be used. Some compilers
|
||||
appear to generate magic section symbols for this purpose.
|
||||
Where we can, we catch such symbols and use our own. This of
|
||||
course is something less than a perfect strategy.
|
||||
2. The table of contents is placed immediately after idata4.
|
||||
The ".private.toc" sections are generated by the ppc bfd. The
|
||||
.toc variable is generated by gas, and resolved here. It is
|
||||
used to initialized function descriptors (and anyone else who
|
||||
needs the address of the module's toc). The only thing
|
||||
interesting about it at all? Most ppc instructions using it
|
||||
have a 16bit displacement field. The convention for addressing
|
||||
is to initialize the .toc value to 32K past the start of the
|
||||
actual toc, and subtract 32K from all references, thus using
|
||||
the entire 64K range. Naturally, the reloc code must agree
|
||||
on this number or you get pretty stupid results.
|
||||
*/
|
||||
.idata BLOCK(__section_alignment__) :
|
||||
{
|
||||
__idata2_magic__ = .;
|
||||
*(.idata\$2);
|
||||
__idata3_magic__ = .;
|
||||
*(.idata\$3);
|
||||
__idata4_magic__ = .;
|
||||
*(.idata\$4);
|
||||
.toc = . + 32768;
|
||||
*(.private.toc);
|
||||
__idata5_magic__ = .;
|
||||
*(.idata\$5);
|
||||
__idata6_magic__ = .;
|
||||
*(.idata\$6);
|
||||
__idata7_magic__ = .;
|
||||
*(.idata\$7);
|
||||
;
|
||||
}
|
||||
|
||||
/* reldata -- data that requires relocation
|
||||
*/
|
||||
.reldata BLOCK(__section_alignment__) :
|
||||
{
|
||||
*(.reldata)
|
||||
;
|
||||
}
|
||||
|
||||
/* We don't do anything useful with codeview debugger support or the
|
||||
directive section (yet). Hopefully, we junk them correctly.
|
||||
*/
|
||||
.junk BLOCK(__section_alignment__) :
|
||||
{
|
||||
*(.debug\$S)
|
||||
*(.debug\$T)
|
||||
*(.debug\$F)
|
||||
*(.drectve)
|
||||
;
|
||||
}
|
||||
|
||||
/* Resources */
|
||||
.rsrc BLOCK(__section_alignment__) :
|
||||
{
|
||||
*(.rsrc\$01)
|
||||
*(.rsrc\$02)
|
||||
;
|
||||
}
|
||||
|
||||
/* The .reloc section is currently generated by the dlltool from Steve
|
||||
Chamberlain in a second pass of linking. Section address and extent
|
||||
are placed in the DataDirectory.
|
||||
*/
|
||||
.reloc BLOCK(__section_alignment__) :
|
||||
{
|
||||
*(.reloc)
|
||||
;
|
||||
}
|
||||
|
||||
.stab BLOCK(__section_alignment__) ${RELOCATING+(NOLOAD)} :
|
||||
{
|
||||
[ .stab ]
|
||||
}
|
||||
|
||||
.stabstr BLOCK(__section_alignment__) ${RELOCATING+(NOLOAD)} :
|
||||
{
|
||||
[ .stabstr ]
|
||||
}
|
||||
}
|
||||
EOF
|
Loading…
Reference in New Issue