d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
kq-head
freebsd-skq/sys/conf/ldscript.amd64

221 lines
7.8 KiB
Plaintext
Raw Permalink 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
{
Unobfuscate "KERNLOAD" parameter on amd64. This change lines-up amd64 with the i386 and the rest of supported architectures by defining KERNLOAD in the vmparam.h and getting rid of magic constant in the linker script, which albeit documented via comment but isn't programmatically accessible at a compile time. Use KERNLOAD to eliminate another (matching) magic constant 100 lines down inside unremarkable TU "copy.c" 3 levels deep in the EFI loader tree. Reviewed by: markj Approved by: markj MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D27355
2020-11-25 23:19:01 +00:00
kernphys = kernload;
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
/* Read-only sections, merged into text segment: */
The new binutils has correctly redefined MAXPAGESIZE on amd64 as 0x200000 instead of 0x100000. As a side effect, an amd64 kernel now loads at physical address 0x200000 instead of 0x100000. This is probably for the best because it avoids the use of a 2MB page mapping for the first 1MB of the kernel that also spans the fixed MTRRs. However, getmemsize() still thinks that the kernel loads at 0x100000, and so the physical memory between 0x100000 and 0x200000 is lost. Fix this problem by replacing the hard-wired constant in getmemsize() by a symbol "kernphys" that is defined by the linker script. In collaboration with: kib
2011-03-28 06:35:17 +00:00
. = kernbase + kernphys + SIZEOF_HEADERS;
amd64: set the correct LMA values The current linker script generates program headers with VMA == LMA: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0xffffffff80200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0xffffffff80200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0xffffffff80200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0xffffffff81456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 This is fine for the FreeBSD loader, because it completely ignores p_paddr and instead uses p_vaddr with a hardcoded offset. Other loaders however acknowledge p_paddr (like the Xen ELF loader), in which case they will try to load the kernel at the wrong place. Fix this by adding an AT keyword to the first section specifying the physical address, other sections will follow suit, so it ends up looking like: Entry point 0xffffffff802e7000 There are 6 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0xffffffff80200040 0x0000000000200040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0xffffffff80200190 0x0000000000200190 0x000000000000000d 0x000000000000000d R 1 [Requesting program interpreter: /red/herring] LOAD 0x0000000000000000 0xffffffff80200000 0x0000000000200000 0x00000000010559b0 0x00000000010559b0 R E 200000 LOAD 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x0000000000132638 0x000000000052ecf8 RW 200000 DYNAMIC 0x0000000001056000 0xffffffff81456000 0x0000000001456000 0x00000000000000d0 0x00000000000000d0 RW 8 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RWE 8 Tested on bare metal using the native FreeBSD loader and grub2 from TRUEOS. Sponsored by: Citrix Systems R&D Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D2783
2015-06-26 07:12:17 +00:00
/*
* Use the AT keyword in order to set the right LMA that contains
* the physical address where the section should be loaded. This is
* needed for the Xen loader which honours the LMA.
*/
.interp : AT (kernphys + SIZEOF_HEADERS) { *(.interp) }
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
.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.*) }
.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))
use INT3 instead of NOP for x86 binary padding We should never end up executing the inter-function padding, so we are better off faulting than silently carrying on to whatever function happens to be next. Note that LLD will soon do this by default (although it currently pads with zeros). Reviewed by: dim, kib MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D10047
2017-03-19 00:22:13 +00:00
} =0xCCCCCCCC
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
.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)
use INT3 instead of NOP for x86 binary padding We should never end up executing the inter-function padding, so we are better off faulting than silently carrying on to whatever function happens to be next. Note that LLD will soon do this by default (although it currently pads with zeros). Reviewed by: dim, kib MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D10047
2017-03-19 00:22:13 +00:00
} =0xCCCCCCCC
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
.fini :
{
KEEP (*(.fini))
use INT3 instead of NOP for x86 binary padding We should never end up executing the inter-function padding, so we are better off faulting than silently carrying on to whatever function happens to be next. Note that LLD will soon do this by default (although it currently pads with zeros). Reviewed by: dim, kib MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D10047
2017-03-19 00:22:13 +00:00
} =0xCCCCCCCC
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
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) }
Expose the kernel's build-ID through sysctl After our migration (of certain architectures) to lld the kernel is built with a unique build-ID. Make it available via a sysctl and uname(1) to allow the user to identify their running kernel. Submitted by: Ali Mashtizadeh <ali_mashtizadeh.com> MFC after: 2 weeks Relnotes: Yes Event: Waterloo Hackathon 2019 Differential Revision: https://reviews.freebsd.org/D20326
2019-06-04 13:07:10 +00:00
.note.gnu.build-id : {
PROVIDE (__build_id_start = .);
*(.note.gnu.build-id)
PROVIDE (__build_id_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
.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));
amd64: Protect the kernel text, data, and BSS by setting the RW/NX bits correctly for the data contained on each memory page. There are several components to this change: * Add a variable to indicate the start of the R/W portion of the initial memory. * Stop detecting NX bit support for each AP. Instead, use the value from the BSP and, if supported, activate the feature on the other APs just before loading the correct page table. (Functionally, we already assume that the BSP and all APs had the same support or lack of support for the NX bit.) * Set the RW and NX bits correctly for the kernel text, data, and BSS (subject to some caveats below). * Ensure DDB can write to memory when necessary (such as to set a breakpoint). * Ensure GDB can write to memory when necessary (such as to set a breakpoint). For this purpose, add new MD functions gdb_begin_write() and gdb_end_write() which the GDB support code can call before and after writing to memory. This change is not comprehensive: * It doesn't do anything to protect modules. * It doesn't do anything for kernel memory allocated after the kernel starts running. * In order to avoid excessive memory inefficiency, it may let multiple types of data share a 2M page, and assigns the most permissions needed for data on that page. Reviewed by: jhb, kib Discussed with: emaste MFC after: 2 weeks Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D14282
2018-03-06 14:28:37 +00:00
PROVIDE (brwsection = .);
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
/* 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) }
amd64: tweak the read_frequently section 1. align to 128 bytes to avoid possible waste from the preceeding section 2. sort entries by alignment SORT_BY_ALIGNMENT, plugging the holes (most entries are one byte in size, but they got interleaved with bigger ones) Interestingly I was looking for a feature of the sort earlier and failed to find it. It turns out the script was already utilizing sorting in other places, so shame on me. Thanks for Travis Geiselbrecht for pointing me at the feature.
2018-05-18 07:31:26 +00:00
. = ALIGN(128);
Introduce __read_frequently While __read_mostly groups variables together, their placement is not specified. In particular 2 frequently used variables can end up in different lines. This annotation is only expected to be used for variables read all the time, e.g. on each syscall entry. MFC after: 1 week
2017-09-06 20:32:49 +00:00
.data.read_frequently :
{
amd64: tweak the read_frequently section 1. align to 128 bytes to avoid possible waste from the preceeding section 2. sort entries by alignment SORT_BY_ALIGNMENT, plugging the holes (most entries are one byte in size, but they got interleaved with bigger ones) Interestingly I was looking for a feature of the sort earlier and failed to find it. It turns out the script was already utilizing sorting in other places, so shame on me. Thanks for Travis Geiselbrecht for pointing me at the feature.
2018-05-18 07:31:26 +00:00
*(SORT_BY_ALIGNMENT(.data.read_frequently))
Introduce __read_frequently While __read_mostly groups variables together, their placement is not specified. In particular 2 frequently used variables can end up in different lines. This annotation is only expected to be used for variables read all the time, e.g. on each syscall entry. MFC after: 1 week
2017-09-06 20:32:49 +00:00
}
Introduce __read_mostly and __exclusive_cache_line macros. The intended use is to annotate frequently used globals which either rarely change (and thus can be grouped in the same cacheline) or are an atomic counter (which means it may benefit from being the only variable in the cacheline). Linker script support is provided only for amd64. Architectures without it risk having other variables put in, i.e. as if they were not annotated. This is harmless from correctness point of view. Reviewed by: bde (previous version) MFC after: 1 month
2017-01-27 14:53:09 +00:00
.data.read_mostly :
{
*(.data.read_mostly)
}
amd64: align the .data.exclusive_cache_line section to 128 This aligns the section itself compared to other sections, does not change internal alignment of fields stored inside. This may or may not come later. The motivation is partially combating adverse effects of the adjacent cache line prefetcher. Without the annotation part of read_mostly section was on the line of fire.
2018-05-11 08:56:39 +00:00
. = ALIGN(128);
Introduce __read_mostly and __exclusive_cache_line macros. The intended use is to annotate frequently used globals which either rarely change (and thus can be grouped in the same cacheline) or are an atomic counter (which means it may benefit from being the only variable in the cacheline). Linker script support is provided only for amd64. Architectures without it risk having other variables put in, i.e. as if they were not annotated. This is harmless from correctness point of view. Reviewed by: bde (previous version) MFC after: 1 month
2017-01-27 14:53:09 +00:00
.data.exclusive_cache_line :
{
*(.data.exclusive_cache_line)
}
amd64: align the .data.exclusive_cache_line section to 128 This aligns the section itself compared to other sections, does not change internal alignment of fields stored inside. This may or may not come later. The motivation is partially combating adverse effects of the adjacent cache line prefetcher. Without the annotation part of read_mostly section was on the line of fire.
2018-05-11 08:56:39 +00:00
. = ALIGN(128);
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 :
{
*(.data .data.* .gnu.linkonce.d.*)
KEEP (*(.gnu.linkonce.d.*personality*))
}
.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)
Tighten mapping protections on preloaded files on amd64. - We load the kernel at 0x200000. Memory below that address need not be executable, so do not map it as such. - Remove references to .ldata and related sections in the kernel linker script. They come from ld.bfd's default linker script, but are not used, and we now use ld.lld to link the amd64 kernel. lld does not contain a default linker script. - Pad the .bss to a 2MB as we do between .text and .data. This forces the loader to load additional files starting in the following 2MB page, preserving the use of superpage mappings for kernel data. - Map memory above the kernel image with NX. The kernel linker now upgrades protections as needed, and other preloaded file types (e.g., entropy, microcode) need not be mapped with execute permissions in the first place. Reviewed by: kib MFC after: 1 month Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D21859
2019-10-18 14:05:13 +00:00
/* Ensure that the .bss section ends at a superpage boundary.
This way it can be mapped using non-executable large pages. */
. = ALIGN(0x200000);
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