History log of /freebsd-current/sys/conf/ldscript.i386
Revision Date Author Comments
# 23dff4fd 29-Feb-2024 Warner Losh <imp@FreeBSD.org>

kernel: Sync ldscript files wrt gnu.attributes and .note.GNU-stack

Bring the keeping of .gnu.attributes to all architectures. Also discard
.note.GNU-stack on all archtiectures. Plus delete obsolete comment that
was removed from i386 in 2010.

Sponsored by: Netflix
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D44069


# 71625ec9 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c comment pattern

Remove /^/[*/]\s*\$FreeBSD\$.*\n/


# 74cd06b4 04-Jun-2019 Ed Maste <emaste@FreeBSD.org>

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


# f3e1dfeb 11-Oct-2018 Dimitry Andric <dim@FreeBSD.org>

Fix placement of __bss_start in i386 kernel linker script

With lld 7.0.0, a rather nasty problem in our kernel linker script came
to light. We use quite a lot of so-called "orphan" sections, e.g.
sections which are not explicitly named in the linker script. Mainly,
these are the linker sets (such as set_sysinit_set).

Note that the placement of these orphan sections is not very well
defined. Usually, any read-only orphan sections get placed after the
last read-only section from the linker script, and similarly for the
read/write variants.

In our linker scripts, there are also symbol assignments like _etext,
_edata, and __bss_start, which are used in various places to refer to
the start or end addresses of sections.

However, some of these symbol assignments are interspersed with output
section descriptions. While the linker will guarantee that a symbol
assignment after some section will stay after that section, there is no
guarantee that an orphan section cannot be inserted just before it.

Take for example the following script:

SECTIONS
{
.data : { *(.data) }
__bss_start = .;
.bss : { *(.bss) }
}

If an orphan section (like set_sysinit_set) is now inserted just after
the __bss_start assignment, __bss_start will actually point to the start
of that orphan section, *not* to the start of the .bss section.

Unfortunately, something like this happened with our i386 kernel linker
script, and since sys/i386/i386/locore.s tries to zero .bss, it ended up
zeroing all the linker sets too, leading to a crash very soon after the
<--BOOT--> message.

To fix this, move the __bss_start symbol assignment *into* the .bss
section description, so there is no way a linker can then insert orphan
sections at that point. Also add a corresponding __bss_end symbol.

In addition, change sys/i386/i386/locore.s, so it clears from
__bss_start to __bss_end, instead of assuming that _edata is just
before .bss (which may not be true), and that _end is just after _bss
(which also may not be true).

This allows an i386 kernel linked with lld 7.0.0 to boot successfully.


# d86c1f0d 13-Apr-2018 Konstantin Belousov <kib@FreeBSD.org>

i386 4/4G split.

The change makes the user and kernel address spaces on i386
independent, giving each almost the full 4G of usable virtual addresses
except for one PDE at top used for trampoline and per-CPU trampoline
stacks, and system structures that must be always mapped, namely IDT,
GDT, common TSS and LDT, and process-private TSS and LDT if allocated.

By using 1:1 mapping for the kernel text and data, it appeared
possible to eliminate assembler part of the locore.S which bootstraps
initial page table and KPTmap. The code is rewritten in C and moved
into the pmap_cold(). The comment in vmparam.h explains the KVA
layout.

There is no PCID mechanism available in protected mode, so each
kernel/user switch forth and back completely flushes the TLB, except
for the trampoline PTD region. The TLB invalidations for userspace
becomes trivial, because IPI handlers switch page tables. On the other
hand, context switches no longer need to reload %cr3.

copyout(9) was rewritten to use vm_fault_quick_hold(). An issue for
new copyout(9) is compatibility with wiring user buffers around sysctl
handlers. This explains two kind of locks for copyout ptes and
accounting of the vslock() calls. The vm_fault_quick_hold() AKA slow
path, is only tried after the 'fast path' failed, which temporary
changes mapping to the userspace and copies the data to/from small
per-cpu buffer in the trampoline. If a page fault occurs during the
copy, it is short-circuit by exception.s to not even reach C code.

The change was motivated by the need to implement the Meltdown
mitigation, but instead of KPTI the full split is done. The i386
architecture already shows the sizing problems, in particular, it is
impossible to link clang and lld with debugging. I expect that the
issues due to the virtual address space limits would only exaggerate
and the split gives more liveness to the platform.

Tested by: pho
Discussed with: bde
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential revision: https://reviews.freebsd.org/D14633


# bd4e4054 18-Mar-2017 Ed Maste <emaste@FreeBSD.org>

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


# 45eff3df 28-Jul-2016 Ed Maste <emaste@FreeBSD.org>

remove CONSTRUCTORS from kernel linker scripts

The linker script CONSTRUCTORS keyword is only meaningful "when linking
object file formats which do not support arbitrary sections, such as
ECOFF and XCOFF"[1] and is ignored for other object file formats.

LLVM's lld does not yet accept (and ignore) CONSTRUCTORS, so just remove
CONSTRUCTORS from the linker scripts as it has no effect.

[1] https://sourceware.org/binutils/docs/ld/Output-Section-Keywords.html

Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D7343


# f646247d 05-Nov-2010 Dimitry Andric <dim@FreeBSD.org>

Step 2: sync sys/conf/ldscript.i386 with the binutils 2.17.50 version,
again preserving FreeBSD-specific customizations.


# 0dd487b0 05-Nov-2010 Dimitry Andric <dim@FreeBSD.org>

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


# a7d5f7eb 19-Oct-2010 Jamie Gritton <jamie@FreeBSD.org>

A new jail(8) with a configuration file, to replace the work currently done
by /etc/rc.d/jail.


# d7f03759 19-Oct-2008 Ulf Lilleengen <lulf@FreeBSD.org>

- Import the HEAD csup code which is the basis for the cvsmode work.


# 211e6809 03-Dec-2003 Poul-Henning Kamp <phk@FreeBSD.org>

Align the .ctors section correctly.

This fixes the 75% probable panic when using basic block profiling.

Approved by: re@


# 6ccf265b 01-Oct-2003 Peter Wemm <peter@FreeBSD.org>

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


# 3fc473df 06-Jan-2003 Poul-Henning Kamp <phk@FreeBSD.org>

Add two symbols start_ctors and stop_ctors to allow us to find the
.ctors section so we can call the constructors.


# 616d2d5d 11-Oct-2002 David E. O'Brien <obrien@FreeBSD.org>

Use the new freebsd output format from Binutils 2.13.1.


# d7ffc002 17-Sep-2001 Peter Wemm <peter@FreeBSD.org>

Remove hard coded magic load address. Now to change the load address,
we just have to change the pmap.h constants and ld will automatically
adapt based on the "kernbase" symbol.


# d0e12656 11-Jan-2000 Peter Wemm <peter@FreeBSD.org>

Add $FreeBSD$
Make the alpha linker script more like the i386 version - delete the
/usr/local and egcs directories


# 5004cc2e 03-Jun-1999 Peter Wemm <peter@FreeBSD.org>

Remove a rather bogus search path reference..


# 8681b974 11-Mar-1999 David Greenman <dg@FreeBSD.org>

Increased kernel virtual address space to 1GB. NOTE: You MUST have fixed
bootblocks in order to boot the kernel after this! Also note that this
change breaks BSDI BSD/OS compatibility.
Also increased default NKPT to 17 so that FreeBSD can boot on machines
with >=2GB of RAM. Booting on machines with exactly 4GB requires other
patches, not included.


# 6b7a14ce 29-Sep-1998 Peter Wemm <peter@FreeBSD.org>

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.