These are required to debug kernel modules. Since we're now able to
do that, there's another reason besides BTF to enable DEBUG_INFO, so
I've done that for pre-BTF kernel modules as well here.
For GDB to get configured correctly, vmlinux-gdb.py has to be two
directories up from scripts/gdb, and vmlinux has to be next to
vmlinux-gdb.py. The least invasive way to satisfy these constraints
is to make vmlinux a symlink, which GDB will resolve before looking
for vmlinux-gdb.py.
Tested both ways of getting the scripts into GDB that I know of:
gdb /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/vmlinux \
-iex 'add-auto-load-safe-path /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/lib/modules/6.1.19/build/vmlinux-gdb.py' \
-ex 'lx-version' \
-ex 'q'
gdb /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/vmlinux \
-ex 'source /nix/store/7n77ijlxkxr6d613h02lr707kvjx6j1k-linux-6.1.19-dev/lib/modules/6.1.19/build/vmlinux-gdb.py' \
-ex 'lx-version' \
-ex 'q'
Also tested that the strip changes don't result in meaningful output
size changes (there's some small variation due to BTF data not always
coming out the same size, which is unrelated), and built every kernel
I can on x86_64 to make sure I'm not relying on build system behaviour
specific to newer kernels.
We've basically been reimplementing this — by default it contains
vmlinux, dtbs (on applicable architectures), modules, and architecture
specific stuff like $(KBUILD_IMAGE) and a couple of other
miscellaneous files.
linux is unusual in that we include its sources in an output. There's
no point unpacking into /build when we're going to copy the sources
into $dev later. Let's unpack directly into the final destination of
the code, and save copying a whole kernel source tree (often across
filesystems!).
This also means that Kbuild knows the location of the sources, which
will allow us to install the GDB scripts — some scripts are generated,
and some are not, so the generated ones end up in the build directory,
accompanied by symlinks to the non-generated ones in the source
directory.
Assuming the dead link refers to
https://lore.kernel.org/linux-kbuild/1443741332.2730.75.camel@decadent.org.uk/
at this point it's fairly safe to say it's not getting in, as it
hasn't been resubmitted since 2015, and nowadays the kernel
documentation just suggests setting KBUILD_BUILD_TIMESTAMP like we do
here.
Linux has a few PowerPC-specific symbols which are marked as GPL exports; these
symbols wound up being exposed in Linux 5.12 and are needed by OpenZFS. The
symbol licensing was fixed in mainline 5.19; this commit backports the fix to
all previous affected kernels.
This commit is required in order to build the NixOS ISO for PowerPC64.
Reverts 7c7c83e233 which was
only needed for the minimal-kernel.nix test module and clutters the call site.
stdenv can still be overridden with `linuxManualConfig.override { stdenv = ...; }`.
The options GCC_PLUGIN_RANDSTRUCT{,_PERFORMANCE} have been renamed to
`RANDSTRUCT_*` in 595b893e2087de306d0781795fb8ec47873596a6 since CLang
is about to support this as well and thus the options had to be
generalized.
Also, the file that is used to generate the seed has changed, only the
reference to the file in the patch was changed on adding Linux 5.19[1]
[1] b4d0cb4497
Since 7a9b6ac39a ("kernel: Enable cross compiling"), commonMakeFlags
has only been used once. Since these flags aren't "common" between
anything any more, they should just be inlined to make the expression
easier to read.
With this change it's ensured that `builtins.unsafeGetAttrPos` actually
points to `<nixpkgs/pkgs/os-specific/linux/kernel/linux-x.y.nix>` when
retrieving the position of `src` or `version` of
`linuxPackages.kernel`.
This is relevant to make sure that ofborg pinging maintainers on kernel updates
actually works[1]. While the underlying issue should be fixed in ofborg
or Nix itself, this is IMHO a pragmatic change to ensure that all kernel
maintainers are automatically notified on updates.
[1] https://github.com/NixOS/nixpkgs/pull/143113#issuecomment-953319957
Now there are a few more folks who should get pinged on kernel changes:
$ nix-instantiate -E 'with import ./. {}; (map (x: x.github) linux.meta.maintainers)' --eval --strict
[ "TredwellGit" "mweinelt" "ma27" "nequissimus" "alyssais" "thoughtpolice" ]
Refs #140281
linux: build DTBs in buildPhase, install with everything else
This improves build speed, especially on machines with lots of cores
such as the aarch64 community box and hydra builders.
BTF is a new, lightweight debug information format tailored specifically
for the needs of eBPF, allowing eBPF programs to be portable across
various kernel versions, configurations and distributions. This is used
by bpftrace and lots of new eBPF-based tooling to avoid a dependency
on LLVM on the host.
BTF debug information is enabled on all major distributions: Fedora 31+,
RHEL 8.2+, Ubuntu 20.10, Debian 11 and ArchLinux all have enabled it.
Enabling BTF debug information requires adding two new dependencies to
the kernel build: Python3 and pahole. Those will be used to generate the
BTF debugging information.
This is just for practicity, as it allows users of buildLinux to pass
along extra flags they need in the kernel's make invocation. This makes,
for example, supporting LLVM _much_ easier, and could enable us in the
future to provide clang-built kernels.
There are many scripts in `scripts/` which may be called by the build,
depending on how the user chooses to configure the kernel. For example,
`scripts/jobserver-exec` is called whenever the kernel is being built
with LLVM tooling, and without this patch that build will fail due to
the broken shebang.
This patch makes us fix _all_ scripts, as well as add a dependency on
python3Minimal, since a lot of the aforementioned scripts are written in
Python3 instead of shell.
In order to have our linux builds be reproducible we patch the
`Makefile` to use `--build-id=none` as opposed to the default
`--build-id=sha1`. The way we've been doing this, however, caused the
flag to be mangled, and being set to `--build-id=none=sha1`. While bfd
seems to parse this normally, lld will loudly complain that the flag
does not exist:
```
linux> LD .tmp_vmlinux.kallsyms1
linux> ld.lld: error: unknown --build-id style: none=sha1
```
With this change the flag is now correctly set to `--build-id=none`.
Xen is now enabled unconditionally on kernels that support it, so the
xen_dom0 feature doesn't do anything. The isXen attribute will now
produce a deprecation warning and unconditionally return true.
Passing in a custom value for isXen is no longer supported.
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
