sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

fbt/x86: update FBT_AFRAMES to match the trap handlers

Reviewed by: markj
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D40054

fbt: get rid of redundant defines

No functional change intended.

Reviewed by: markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39882

dtrace: Fix the i386 FBT build

Reported by: Jenkins
Fixes: 0e69c959150c ("dtrace: Fix up %rip for invop probes on x86")

dtrace: Fix up %rip for invop probes on x86

When a breakpoint exception is raised, the saved value of %rip points to
the instruction following the breakpoint. However, when fetching the
value of %rip using regs[], it's more natural to provide the address of
the breakpoint itself, so modify the kinst and fbt providers accordingly.

Reported by: khng
Reviewed by: christos, khng
MFC after: 2 months
Differential Revision: https://reviews.freebsd.org/D37218

fbt/x86: Extract arg1 for return probes from the trapframe

dtrace invop handlers have access to the whole trapframe, just use that
to extract %rax/%eax for return probes instead of relying on an
additional parameter to the handler. No functional change intended.

MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation

Allow multiple FBT probes to share a tracepoint.

With GNU ifuncs, multiple FBT probes may correspond to the same
instruction. fbt_invop() assumed that this could not happen and
would return after the first probe found in the global FBT hash
table, which might not be the one that's enabled. Fix the problem
on x86 by linking probes that share a tracepoint and having each
linked probe fire when the tracepoint is hit.

PR: 230846
Approved by: re (gjb)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D16921

Revert part of r331264: disable interrupts before disabling WP.

We might otherwise be preempted, leaving WP disabled while another
thread runs on the CPU.

Reported by: kib
X-MFC with: r331264

Make use of the KPI added in r331252.

MFC after: 2 weeks

Unbreak amd64 FBT after r330539.

X-MFC with: r330539

Revert crap accidentally committed

Revert r312923 a better approach will be taken later

Consistently use fbt_excluded() on all architectures.

MFC after: 2 weeks

Allow tracing of functions prefixed by "__".

This restriction was inherited from upstream but is not relevant on FreeBSD.
Furthermore, it hindered the tracing of locking primitive subroutines.

MFC after: 1 week

Make the second argument of dtrace_invop() a trapframe pointer.

Currently this argument is a pointer into the stack which is used by FBT
to fetch the first five probe arguments. On all non-x86 architectures it's
simply the trapframe address, so this change has no functional impact. On
amd64 it's a pointer into the trapframe such that stack[1 .. 5] gives the
first five argument registers, which are deliberately grouped together in
the amd64 trapframe definition.

A trapframe argument simplifies the invop handlers on !x86 and makes the
x86 FBT invop handler easier to understand. Moreover, it allows for invop
handlers that may want to modify the register set of the interrupted thread.

Remove a couple of unused fields from the FBT probe struct.

Factor out the common code for function boundary tracing instead of
duplicating the entire implementation for both x86 and powerpc. This makes
it easier to add support for other architectures and has no functional
impact.

Phabric: D613
Reviewed by: gnn, jhibbits, rpaulo
Tested by: jhibbits (powerpc)
MFC after: 2 weeks