Ports bsd.kmod.mk explicitly sets MK_KERNEL_SYMBOLS=no to prevent auto-
splitting of debuginfo from kernel modules. If that knob is set, don't
split out a .ko.debug and .ko from .ko.full; just generate a .ko with
debuginfo and leave it be.
Otherwise, with DEBUG_FLAGS set and MK_KERNEL_SYMBOLS=no, we would helpfully
strip out the debuginfo from the .ko.full and then not install it. That is
not the desired result a WITH_DEBUG port kmod build.
Reviewed by: emaste, jhb
Differential Revision: https://reviews.freebsd.org/D24835
-development is long and awkward, and is also inconsistent with prior art
from the Linux world, which uses -dev (Debian) or -devel (Red Hat). Follow
the Debian convention, and similarly for debug info packages.
Also remove redundant pkgbase development tag from includes. We already tag
include files with package=runtime,dev; there is no need to separately tag
them as dev.
Discussed with: bapt
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24139
Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree.
Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions
for older compilers.
Reviewed by: imp (earlier version), emaste, jhb
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D24802
-fno-common will become the default in GCC10/LLVM11. Plenty of work has been
put in to make sure our world builds are no -fno-common clean, so let's slap
the build with this until it becomes the compiler default to ensure we don't
regress.
At this time, we will not be enforcing -fno-common on ports builds. I
suspect most ports will be or quickly become -fno-common clean as they're
naturally built against compilers that default to it, so this will hopefully
become a non-issue in due time. The exception to this, which is actually the
status quo, is that kmods built from ports will continue to build with
-fno-common.
As of the time of writing, I intend to also make stable/12 -fno-common
clean. What's been done will be MFC'd to stable/11 if it's easily applicable
and/or not much work to massage it into being functional, but I anticipate
adding -fcommon to stable/11 builds to maintain its ability to be built with
newer compilers for the rest of its lifetime instead of putting in a third
branch's worth of effort.
Centralize the list of generated files required by linuxkpi consumers,
into the common variable. This way, consumers that use the variable
are insulated from possible changes in the list.
Reviewed by: hselasky, imp
Sponsored by: Mellanox Technologies
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D24137
For untied module builds, we'll generate opt_foo headers if they're included
in SRCS. However, options that would normally be represented in opt_global.h
aren't properly represented.
Start generating opt_global.h with #define VIMAGE for !mips since it's
almost universally a project default and right now kmods must hack it in
themselves in order to be properly compiled for the default kernel. For
example, ^/sys/modules/pf/Makefile
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D23345
To improve reliability of kernel modules after the clang switch, switch to
-fPIC when building for now.
This bypasses some limitations to the way clang and LLD handle relocations,
and is a more robustly tested compilation regime than the
"static shared object" mode that we were previously attempting to convince
the compiler stack to use.
The kernel linker was recently augmented to be able to handle this mode.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D22798
This Makefile sets KERN_OPTS. This permits kernel module Makefiles to
use KERN_OPTS to control the value of variables such as SRCS that are
used by bsd.kmod.mk for KERN_OPTS values that honor WITH/WITHOUT
options for standalone builds.
In the past, we would add symbolic links for MACHINE_CPUARCH when it differed
from MACHINE. This was for pc98 only, however. All other architectures didn't
need this and it was really due to pc98 pulling from i386 rather than something
more intrinsic. At the time, we had the split we did to mimic what NetBSD did
for its 68k ports where many different kernels were possible for the same
architecture. Since then, both projects have moved away from this convention to
having a more generic MACHINE for each architecture. FreeBSD's new arm64/aarch64
breaks this old notion and so was an exception to the rule. So, we no longer
need to create this link for any old machine or any new machine, delete it
entirely.
Differential Revision: https://reviews.freebsd.org/D22246
Use a separate make variable to specify the linker script so that it is
only applied at link time and not during intermediate generation of .fwo
files.
This ensures that the .text padding inserted by the amd64 linker script
is applied to the stub module load handlers embedded in firmware
modules.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D22125
Automatically apply ldscript.kmod.${MACHINE_ARCH} if it exists.
We already have an i386-specific linker script; rename it accordingly.
Note that the linker script is applied when the object files are
partially linked. (For amd64 this is also the final link.)
Reviewed by: imp, kib
Discussed with: jhb
MFC after: 1 week
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D21887
binaries (e.g. on any arch except amd64 and mips).
Otherwise, with lld 9, after https://reviews.llvm.org/rLLD356117, the
modules will get an additional PT_LOAD segment, which blows up kldxref,
since that has a hardcoded limit of 3 segments.
I could have alternatively bumped up that limit, but since kernel
modules do not use relro, the simplest workaround is to explicitly
disable it.
As part of marching gcc 4.2.1 out of the tree, turn off -Werror on gcc 4.2.1
compiles by default. It generates too many false positives and breaks CI
for no benefit.
Discussed on: arch@
Reviewed by: jhb@, emaste@, pfg@
Differential Revision: https://reviews.freebsd.org/D21378
with an eventual goal to convert all legacl zlib callers to the new zlib
version:
* Move generic zlib shims that are not specific to zlib 1.0.4 to
sys/dev/zlib.
* Connect new zlib (1.2.11) to the zlib kernel module, currently built
with Z_SOLO.
* Prefix the legacy zlib (1.0.4) with 'zlib104_' namespace.
* Convert sys/opencrypto/cryptodeflate.c to use new zlib.
* Remove bundled zlib 1.2.3 from ZFS and adapt it to new zlib and make
it depend on the zlib module.
* Fix Z_SOLO build of new zlib.
PR: 229763
Submitted by: Yoshihiro Ota <ota j email ne jp>
Reviewed by: markm (sys/dev/zlib/zlib_kmod.c)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D19706
This was lost in r335910 for some reason.
This also fixes a META_MODE rebuild issue in some modules [1].
MFC after: 2 weeks
Reported by: npn [1]
Sponsored by: DellEMC
Apply a linker script when linking i386 kernel modules to apply padding
to a set_pcpu or set_vnet section. The padding value is kind-of random
and is used to catch modules not compiled with the linker-script, so
possibly still having problems leading to kernel panics.
This is needed as the code generated on certain architectures for
non-simple-types, e.g., an array can generate an absolute relocation
on the edge (just outside) the section and thus will not be properly
relocated. Adding the padding to the end of the section will ensure
that even absolute relocations of complex types will be inside the
section, if they are the last object in there and hence relocation will
work properly and avoid panics such as observed with carp.ko or ipsec.ko.
There is a rather lengthy discussion of various options to apply in
the mentioned PRs and their depends/blocks, and the review.
There seems no best solution working across multiple toolchains and
multiple version of them, so I took the liberty of taking one,
as currently our users (and our CI system) are hitting this on
just i386 and we need some solution. I wish we would have a proper
fix rather than another "hack".
Also backout r340009 which manually, temporarily fixed CARP before 12.0-R
"by chance" after a lead-up of various other link-elf.c and related fixes.
PR: 230857,238012
With suggestions from: arichardson (originally last year)
Tested by: lwhsu
Event: Waterloo Hackathon 2019
Reported by: lwhsu, olivier
MFC after: 6 weeks
Differential Revision: https://reviews.freebsd.org/D17512
Add a CAM-Newbus SDIO support module. This works provides a newbus
infrastructure for device drivers wanting to use SDIO. On the lower end
while it is connected by newbus to SDHCI, it talks CAM using the MMCCAM
framework to get to it.
This also duplicates the usbdevs framework to equally create sdiodev
header files with #defines for "vendors" and "products".
Submitted by: kibab (initial work, see https://reviews.freebsd.org/D12467)
Reviewed by: kibab, imp (comments on earlier version)
MFC after: 6 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19749
install -> ${INSTALL}
mtree -> ${MTREE_CMD}
services_mkdb -> ${SERVICES_MKDB_CMD}
cap_mkdb -> ${CAP_MKDB_CMD}
pwd_mkdb -> ${PWD_MKDB_CMD}
kldxref -> ${KLDXREF_CMD}
If you do custom FreeBSD builds you may want to override those
in some cases.
Sponsored by: Sippy Software, Inc.
We were doing so as a workaround for the problem addressed by r345593, so
it's no longer necessary.
Reviewed by: jhb
Discussed with: emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19705
The kernel build uses symlinks to make MD #includes like <machine/pcpu.h>
work. Debug info ends up referencing these symlinks in a relative path,
so debuggers generally don't know how to find the corresponding headers.
Address this by using -fdebug-prefix-map to map relative paths through
the symlinks to their absolute paths in the source tree. This is
consistent with how regular source file paths are defined in the
kernel's debug info.
Also map the current directory to an absolute path to the object
directory. This gives debuggers a chance to find auto-generated files
like vnode_if.c if the object directory is available.
Reviewed by: emaste, jhb (previous version)
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19633
add gcov support and export results as files in debugfs
Reviewed by: hps@
MFC after: 1 week
Sponsored by: iX Systems
Differential Revision: https://reviews.freebsd.org/D19260
This allows us to build the ubsan code added in r340189 into the kernel
with the KUBSAN option. This will report when undefined behaviour is
detected in the currently running kernel.
As it can be large, the kernel is 65MB on arm64, loader may not be able to
load the kernel on all architectures so is disabled by default for now.
Sponsored by: DARPA, AFRL
- inline atomics in modules on i386 and amd64 (they were always
inline on other arches)
- allow modules to opt in to inlining locks by specifying
MODULE_TIED=1 in the makefile
Reviewed by: kib
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D16079
This was inadvertently overriding the first found SYSDIR with the last
of /usr/src which could result in the wrong headers being used if not
building from /usr/src.
SYSDIR?= is not used here to avoid evaluating the exists() when unneeded.
Reported by: rgrimes, sjg, Mark Millard
Pointyhat to: bdrewery
Sponsored by: Dell EMC
assym is only to be included by other .s files, and should never
actually be assembled by itself.
Reviewed by: imp, bdrewery (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D14180
EXPORT_SYMS can be set to YES, NO, a list of symbols to export from a
module, or to a filename containing such a list. For the case that it
is set to a symbol list, replace spaces in the list with newlines, so
the created file is in the format expected by kmod_syms.awk.
Reviewed by: imp, jhb
MFC after: 1 month
Sponsored by: Turing Robotic Industries Inc.
Differential Revision: https://reviews.freebsd.org/D14284
Both flags do the same thing but -n is more widely supported.
Reviewed By: jhb, emaste
Approved By: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D13936
Without this change, modules will match the default compiler
configuration which may not be the same as the kernel values.
Reviewed by: imp
Obtained from: CheriBSD
MFC after: 2 weeks
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D11633
A Build-ID is an identifier generated at link time to uniquely identify
ELF binaries. It allows efficient confirmation that an executable or
shared library and a corresponding standalone debuginfo file match.
(Otherwise, a checksum of the debuginfo file must be calculated when
opening it in a debugger.)
The FreeBSD base system includes GNU bfd ld 2.17.50 as the linker for
architectures other than arm64. Build-ID support was added to bfd ld
shortly after that version, so was not previously available to us.
We can now start making use of Build-ID as we migrate to using lld or
bfd ld from ports, conditionally enabled based on the LINKER_TYPE and
LINKER_VERSION make variables added in r320244 and subsequent commits.
Reviewed by: dim
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11314
Relocatable linking in aarch64 ld from binutils 2.25.1 does not work.
The linker corrupts the references to the external symbols which are
defined by other object in the linking set and should therefore lose
the GOT entry.
The problem is fixed in later versions of GNU ld and does not exist in
the in-tree lld linker that we now use by default for arm64, so the
workaround can be removed.
Reviewed by: kib
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11302
ARM kernel modules require .text relocations (DT_TEXTREL) in shared
object ouptut, which is not allowed by default by lld. Add the -znotext
option to enable this. For simplicity add it unconditionally: it is
already default and thus either redundant (GNU BFD ld and gold from
ports) or ignored as an unknown option (GNU BFD ld 2.17.50 in the base
system).
Reviewed by: kib
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D11250
stack modules.
It adds support for mangling symbols exported by a module by prepending
a string to them. (This avoids overlapping symbols in the kernel linker.)
It allows the use of a macro as the module name in the DECLARE_MACRO()
and MACRO_VERSION() macros.
It allows the code to register stack aliases (e.g. both a generic name
["default"] and version-specific name ["default_10_3p1"]).
With these changes, it is trivial to compile TCP stack modules with
the name defined in the Makefile and to load multiple versions of the
same stack simultaneously. This functionality can be used to enable
side-by-side testing of an old and new version of the same TCP stack.
It also could support upgrading the TCP stack without a reboot.
Reviewed by: gnn, sjg (makefiles only)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D11086
