d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
2ca4998342
freebsd-dev/sys/conf/ldscript.i386

200 lines
7.4 KiB
Plaintext
Raw Normal View History

Add $FreeBSD$ Make the alpha linker script more like the i386 version - delete the /usr/local and egcs directories
2000-01-11 15:35:16 +00:00
/* $FreeBSD$ */
Use the new freebsd output format from Binutils 2.13.1.
2002-10-11 19:38:04 +00:00
OUTPUT_FORMAT("elf32-i386-freebsd", "elf32-i386-freebsd", "elf32-i386-freebsd")
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
OUTPUT_ARCH(i386)
ENTRY(btext)
Remove a rather bogus search path reference..
1999-06-03 22:07:41 +00:00
SEARCH_DIR(/usr/lib);
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
SECTIONS
{
/* Read-only sections, merged into text segment: */
Commit Bosko's patch to clean up the PSE/PG_G initialization to and avoid problems with some Pentium 4 cpus and some older PPro/Pentium2 cpus. There are several problems, some documented in Intel errata. This patch: 1) moves the kernel to the second page in the PSE case. There is an errata that says that you Must Not point a 4MB page at physical address zero on older cpus. We avoided bugs here due to sheer luck. 2) sets up PSE page tables right from the start in locore, rather than trying to switch from 4K to 4M (or 2M) pages part way through the boot sequence at the same time that we're messing with PG_G. For some reason, the pmap work over the last 18 months seems to tickle the problems, and the PAE infrastructure changes disturb the cpu bugs even more. A couple of people have reported a problem with APM bios calls during boot. I'll work with people to get this resolved. Obtained from: bmilekic
2003-10-01 23:46:08 +00:00
. = kernbase + kernload + SIZEOF_HEADERS;
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.interp : { *(.interp) }
.hash : { *(.hash) }
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
.gnu.hash : { *(.gnu.hash) }
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.init : { *(.rel.init) }
.rela.init : { *(.rela.init) }
.rel.text : { *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) }
.rela.text : { *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) }
.rel.fini : { *(.rel.fini) }
.rela.fini : { *(.rela.fini) }
.rel.rodata : { *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) }
.rela.rodata : { *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*) }
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
.rel.data.rel.ro : { *(.rel.data.rel.ro* .rel.gnu.linkonce.d.rel.ro.*) }
.rela.data.rel.ro : { *(.rela.data.rel.ro* .rela.gnu.linkonce.d.rel.ro.*) }
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.rel.data : { *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*) }
.rela.data : { *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*) }
.rel.tdata : { *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*) }
.rela.tdata : { *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*) }
.rel.tbss : { *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*) }
.rela.tbss : { *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*) }
.rel.ctors : { *(.rel.ctors) }
.rela.ctors : { *(.rela.ctors) }
.rel.dtors : { *(.rel.dtors) }
.rela.dtors : { *(.rela.dtors) }
.rel.got : { *(.rel.got) }
.rela.got : { *(.rela.got) }
.rel.bss : { *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*) }
.rela.bss : { *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*) }
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init :
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
{
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
KEEP (*(.init))
} =0x90909090
.plt : { *(.plt) }
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
KEEP (*(.text.*personality*))
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
} =0x90909090
.fini :
{
KEEP (*(.fini))
} =0x90909090
PROVIDE (__etext = .);
PROVIDE (_etext = .);
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
PROVIDE (etext = .);
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1 : { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
.eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RO { *(.gcc_except_table .gcc_except_table.*) }
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
. = ALIGN (CONSTANT (MAXPAGESIZE)) - ((CONSTANT (MAXPAGESIZE) - .) & (CONSTANT (MAXPAGESIZE) - 1)); . = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE));
/* Exception handling */
.eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RW { *(.gcc_except_table .gcc_except_table.*) }
/* Thread Local Storage sections */
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
.preinit_array :
{
PROVIDE_HIDDEN (__preinit_array_start = .);
KEEP (*(.preinit_array))
PROVIDE_HIDDEN (__preinit_array_end = .);
}
.init_array :
{
PROVIDE_HIDDEN (__init_array_start = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))
PROVIDE_HIDDEN (__init_array_end = .);
}
.fini_array :
{
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP (*(.fini_array))
KEEP (*(SORT(.fini_array.*)))
PROVIDE_HIDDEN (__fini_array_end = .);
}
Add two symbols start_ctors and stop_ctors to allow us to find the .ctors section so we can call the constructors.
2003-01-06 07:37:15 +00:00
_start_ctors = .;
PROVIDE (start_ctors = .);
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.ctors :
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
{
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
KEEP (*crtbegin.o(.ctors))
KEEP (*crtbegin?.o(.ctors))
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
/* We don't want to include the .ctor section from
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
the crtend.o file until after the sorted ctors.
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
}
Add two symbols start_ctors and stop_ctors to allow us to find the .ctors section so we can call the constructors.
2003-01-06 07:37:15 +00:00
_stop_ctors = .;
PROVIDE (stop_ctors = .);
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.dtors :
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
{
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
KEEP (*crtbegin.o(.dtors))
KEEP (*crtbegin?.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
}
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.jcr : { KEEP (*(.jcr)) }
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
.data.rel.ro : { *(.data.rel.ro.local* .gnu.linkonce.d.rel.ro.local.*) *(.data.rel.ro* .gnu.linkonce.d.rel.ro.*) }
.dynamic : { *(.dynamic) }
.got : { *(.got) }
. = DATA_SEGMENT_RELRO_END (12, .);
.got.plt : { *(.got.plt) }
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
KEEP (*(.gnu.linkonce.d.*personality*))
SORT(CONSTRUCTORS)
}
.data1 : { *(.data1) }
_edata = .; PROVIDE (edata = .);
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
__bss_start = .;
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.bss :
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
{
*(.dynbss)
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
*(.bss .bss.* .gnu.linkonce.b.*)
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
*(COMMON)
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
/* Align here to ensure that the .bss section occupies space up to
_end. Align after .bss to ensure correct alignment even if the
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
.bss section disappears because there are no input sections.
FIXME: Why do we need it? When there is no .bss section, we don't
pad the .data section. */
. = ALIGN(. != 0 ? 32 / 8 : 1);
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
}
. = ALIGN(32 / 8);
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
. = ALIGN(32 / 8);
_end = .; PROVIDE (end = .);
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
. = DATA_SEGMENT_END (.);
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
/* Stabs debugging sections. */
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
.stab.indexstr 0 : { *(.stab.indexstr) }
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.comment 0 : { *(.comment) }
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version, again preserving FreeBSD-specific customizations.
2010-11-05 19:40:27 +00:00
/* DWARF 3 */
.debug_pubtypes 0 : { *(.debug_pubtypes) }
.debug_ranges 0 : { *(.debug_ranges) }
.gnu.attributes 0 : { KEEP (*(.gnu.attributes)) }
Step 1: sync sys/conf/ldscript.i386 with the binutils 2.15 version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-05 19:30:30 +00:00
/DISCARD/ : { *(.note.GNU-stack) }
Make the ELF kernel build produce a dynamic executable (!). This enables the in-kernel linker to access the _DYNAMIC data for doing loadable elf modules. The alpha kernel is already done this way, I've borrowed some of the hacks from there. This is primarily aimed at the 3-stage boot process which is intended to be able to do pre-loading of kernel modules. Note that the entry point isn't 0xf0100000 any more, it'll be a little further on - but this value is stored in the headers. I don't think this will be a problem, but I'm sure somebody will tell me if it is. :-) I'm not sure if btxboot is going to like this, it doesn't do proper ELF header checking and assumes that there are exactly two program header entries and that they are both PT_LOAD entries - a bad assumption.
1998-09-30 12:14:39 +00:00
}
Reference in New Issue Copy Permalink