MFC r315522: 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 does this by default.

Sponsored by: The FreeBSD Foundation

MFC r323235,r323236,r324789,r324863:

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.

=============

Sprinkle __read_frequently on few obvious places.

Note that some of annotated variables should probably change their types
to something smaller, preferably bit-sized.

=============

Mark kdb_active as __read_frequently and switch to bool to eat less space.

=============

Change kdb_active type to u_char.

Fixes warnings from gcc and keeps the small size. Perhaps nesting should be moved
to another variablle.

MFC r309151: Use explicit 0x200000 for the amd64 kernel physaddr

(instead of MAXPAGESIZE)

MAXPAGESIZE is not well defined by the GNU ld documentation.
Different linkers, and different versions of the same linker, use
different MAXPAGESIZE values. Current versions of GNU gold and LLVM's
lld use 4K. When set to 4K the kernel panics at boot due to an issue
with x86bios.

Here we want the kernel physaddr to be the amd64 superpage size, so use
that value (2MB) explicitly. With this change GNU gold and LLVM lld can
link a working amd64 kernel.

PR: 214718 (x86bios)
Sponsored by: The FreeBSD Foundation

MFC r303442, r305343: remove CONSTRUCTORS from linker scripts

r303442: remove CONSTRUCTORS from kernel linker scripts

r305343: remove CONSTRUCTORS from MIPS uboot linker script

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 script as it has no effect.

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

Reported by: andrew
Sponsored by: The FreeBSD Foundation

MFC r312888:

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.

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

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

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

Merge binutils 2.17.50 to head. This brings a number of improvements to
x86 CPU support, better support for powerpc64, some new directives, and
many other things. Bump __FreeBSD_version, and add a note to UPDATING.

Thanks to the many people that have helped to test this.

Obtained from: projects/binutils-2.17

Provide the _start_ctors and _stop_ctors symbols. As on i386, the addresses
of these are the start and end of the .ctors section.

Sync up with the files in the hammer branch in the p4 tree to get basic
AMD64 support. There is still more to add.

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

Use the new freebsd output format from Binutils 2.13.1.

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.

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

Remove a rather bogus search path reference..

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.

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.