mirror/freebsd
1
0
Fork 0
mirror of https://git.FreeBSD.org/src.git synced 2024-12-29 12:03:03 +00:00
Code Issues Releases Activity
ade7b47061
freebsd/sys/conf/ldscript.amd64

221 lines
8.3 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 new output format 'elf64-x86-64-freebsd' instead of 'elf64-x86-64', and similarly 'elf64-sparc-freebsd' instead of 'elf64-sparc'.
2010-11-01 20:20:31 +00:00
OUTPUT_FORMAT("elf64-x86-64-freebsd", "elf64-x86-64-freebsd", "elf64-x86-64-freebsd")
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
OUTPUT_ARCH(i386:x86-64)
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
ENTRY(btext)
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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: */
Binutils commit 0c845abb5a0083c6deebc75975608237015badba increased ELF_MAXPAGESIZE for amd64 from 0x00100000 to 0x00200000. This caused the kernel to be incorrectly linked, using the existing linker script, resulting in a virtual address of 0xffffffff80000000 for the LOAD program header. The boot loader will load such a kernel at a real address of 0x00000000, which either causes protection faults in btx, crashes the machine, or (in case of a VMware guest) even makes it power down. :) Fix this by partially synchronizing the amd64 linker script with binutils own updated version, in particular replacing a hardcoded value of 0x00100000 by CONSTANT(MAXPAGESIZE).
2010-11-04 18:57:51 +00:00
. = kernbase + CONSTANT (MAXPAGESIZE) + SIZEOF_HEADERS;
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
.interp : { *(.interp) }
.hash : { *(.hash) }
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +00:00
.gnu.hash : { *(.gnu.hash) }
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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.*) }
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +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.*) }
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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.*) }
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +00:00
.rel.ldata : { *(.rel.ldata .rel.ldata.* .rel.gnu.linkonce.l.*) }
.rela.ldata : { *(.rela.ldata .rela.ldata.* .rela.gnu.linkonce.l.*) }
.rel.lbss : { *(.rel.lbss .rel.lbss.* .rel.gnu.linkonce.lb.*) }
.rela.lbss : { *(.rela.lbss .rela.lbss.* .rela.gnu.linkonce.lb.*) }
.rel.lrodata : { *(.rel.lrodata .rel.lrodata.* .rel.gnu.linkonce.lr.*) }
.rela.lrodata : { *(.rela.lrodata .rela.lrodata.* .rela.gnu.linkonce.lr.*) }
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
.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
{
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
KEEP (*(.init))
} =0x90909090
.plt : { *(.plt) }
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +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)
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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 = .);
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1 : { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +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. */
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +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 */
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +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 = .);
}
Provide the _start_ctors and _stop_ctors symbols. As on i386, the addresses of these are the start and end of the .ctors section.
2004-05-29 01:09:00 +00:00
_start_ctors = .;
PROVIDE (start_ctors = .);
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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
{
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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. */
KEEP (*crtbegin.o(.ctors))
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +00:00
KEEP (*crtbegin?.o(.ctors))
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
/* We don't want to include the .ctor section from
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +00:00
the crtend.o file until after the sorted ctors.
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +00:00
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .ctors))
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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
}
Provide the _start_ctors and _stop_ctors symbols. As on i386, the addresses of these are the start and end of the .ctors section.
2004-05-29 01:09:00 +00:00
_stop_ctors = .;
PROVIDE (stop_ctors = .);
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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
{
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
KEEP (*crtbegin.o(.dtors))
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +00:00
KEEP (*crtbegin?.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend.o *crtend?.o ) .dtors))
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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
}
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
.jcr : { KEEP (*(.jcr)) }
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +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 (24, .);
.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 = .;
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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)
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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)
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +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 ? 64 / 8 : 1);
}
.lbss :
{
*(.dynlbss)
*(.lbss .lbss.* .gnu.linkonce.lb.*)
*(LARGE_COMMON)
}
. = ALIGN(64 / 8);
.lrodata ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)) :
{
*(.lrodata .lrodata.* .gnu.linkonce.lr.*)
}
.ldata ALIGN(CONSTANT (MAXPAGESIZE)) + (. & (CONSTANT (MAXPAGESIZE) - 1)) :
{
*(.ldata .ldata.* .gnu.linkonce.l.*)
. = ALIGN(. != 0 ? 64 / 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
}
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +00:00
. = ALIGN(64 / 8);
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +00:00
_end = .; PROVIDE (end = .);
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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. */
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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) }
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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 */
Sync up with the files in the hammer branch in the p4 tree to get basic AMD64 support. There is still more to add.
2003-05-01 02:59:24 +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) }
Sync sys/conf/ldscript.amd64 with the upstream version, preserving FreeBSD-specific customizations (in particular, the addition of _start_ctors and _stop_ctors).
2010-11-04 20:22:44 +00:00
/* DWARF 3 */
.debug_pubtypes 0 : { *(.debug_pubtypes) }
.debug_ranges 0 : { *(.debug_ranges) }
.gnu.attributes 0 : { KEEP (*(.gnu.attributes)) }
/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