kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS
include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
as a placeholder.
Genksyms writes the version CRCs into the linker script, which will be
used for filling the __crc_* symbols. The linker script format depends
on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
to the reference of CRC.
It is time to get rid of this complexity.
Now that modpost parses text files (.*.cmd) to collect all the CRCs,
it can generate C code that will be linked to the vmlinux or modules.
Generate a new C file, .vmlinux.export.c, which contains the CRCs of
symbols exported by vmlinux. It is compiled and linked to vmlinux in
scripts/link-vmlinux.sh.
Put the CRCs of symbols exported by modules into the existing *.mod.c
files. No additional build step is needed for modules. As before,
*.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
No linker magic is used here. The new C implementation works in the
same way, whether CONFIG_RELOCATABLE is enabled or not.
CONFIG_MODULE_REL_CRCS is no longer needed.
Previously, Kbuild invoked additional $(LD) to update the CRCs in
objects, but this step is unneeded too.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM-14 (x86-64)
2022-05-13 20:39:22 +09:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
|
|
2022-09-28 15:39:41 +09:00
|
|
|
PHONY := __default
|
|
|
|
|
__default: vmlinux
|
|
|
|
|
|
kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS
include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
as a placeholder.
Genksyms writes the version CRCs into the linker script, which will be
used for filling the __crc_* symbols. The linker script format depends
on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
to the reference of CRC.
It is time to get rid of this complexity.
Now that modpost parses text files (.*.cmd) to collect all the CRCs,
it can generate C code that will be linked to the vmlinux or modules.
Generate a new C file, .vmlinux.export.c, which contains the CRCs of
symbols exported by vmlinux. It is compiled and linked to vmlinux in
scripts/link-vmlinux.sh.
Put the CRCs of symbols exported by modules into the existing *.mod.c
files. No additional build step is needed for modules. As before,
*.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
No linker magic is used here. The new C implementation works in the
same way, whether CONFIG_RELOCATABLE is enabled or not.
CONFIG_MODULE_REL_CRCS is no longer needed.
Previously, Kbuild invoked additional $(LD) to update the CRCs in
objects, but this step is unneeded too.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM-14 (x86-64)
2022-05-13 20:39:22 +09:00
|
|
|
include include/config/auto.conf
|
|
|
|
|
include $(srctree)/scripts/Kbuild.include
|
|
|
|
|
include $(srctree)/scripts/Makefile.lib
|
|
|
|
|
|
2022-09-28 15:39:41 +09:00
|
|
|
targets :=
|
|
|
|
|
|
kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS
include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
as a placeholder.
Genksyms writes the version CRCs into the linker script, which will be
used for filling the __crc_* symbols. The linker script format depends
on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
to the reference of CRC.
It is time to get rid of this complexity.
Now that modpost parses text files (.*.cmd) to collect all the CRCs,
it can generate C code that will be linked to the vmlinux or modules.
Generate a new C file, .vmlinux.export.c, which contains the CRCs of
symbols exported by vmlinux. It is compiled and linked to vmlinux in
scripts/link-vmlinux.sh.
Put the CRCs of symbols exported by modules into the existing *.mod.c
files. No additional build step is needed for modules. As before,
*.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
No linker magic is used here. The new C implementation works in the
same way, whether CONFIG_RELOCATABLE is enabled or not.
CONFIG_MODULE_REL_CRCS is no longer needed.
Previously, Kbuild invoked additional $(LD) to update the CRCs in
objects, but this step is unneeded too.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM-14 (x86-64)
2022-05-13 20:39:22 +09:00
|
|
|
%.o: %.c FORCE
|
2024-11-14 08:45:22 +09:00
|
|
|
$(call if_changed_rule,cc_o_c)
|
kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS
include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
as a placeholder.
Genksyms writes the version CRCs into the linker script, which will be
used for filling the __crc_* symbols. The linker script format depends
on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
to the reference of CRC.
It is time to get rid of this complexity.
Now that modpost parses text files (.*.cmd) to collect all the CRCs,
it can generate C code that will be linked to the vmlinux or modules.
Generate a new C file, .vmlinux.export.c, which contains the CRCs of
symbols exported by vmlinux. It is compiled and linked to vmlinux in
scripts/link-vmlinux.sh.
Put the CRCs of symbols exported by modules into the existing *.mod.c
files. No additional build step is needed for modules. As before,
*.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
No linker magic is used here. The new C implementation works in the
same way, whether CONFIG_RELOCATABLE is enabled or not.
CONFIG_MODULE_REL_CRCS is no longer needed.
Previously, Kbuild invoked additional $(LD) to update the CRCs in
objects, but this step is unneeded too.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM-14 (x86-64)
2022-05-13 20:39:22 +09:00
|
|
|
|
2024-09-23 16:56:03 +09:00
|
|
|
%.o: %.S FORCE
|
2024-11-14 08:45:22 +09:00
|
|
|
$(call if_changed_rule,as_o_S)
|
2024-09-23 16:56:03 +09:00
|
|
|
|
|
|
|
|
# Built-in dtb
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
quiet_cmd_wrap_dtbs = WRAP $@
|
|
|
|
|
cmd_wrap_dtbs = { \
|
|
|
|
|
echo '\#include <asm-generic/vmlinux.lds.h>'; \
|
|
|
|
|
echo '.section .dtb.init.rodata,"a"'; \
|
|
|
|
|
while read dtb; do \
|
|
|
|
|
symbase=__dtb_$$(basename -s .dtb "$${dtb}" | tr - _); \
|
|
|
|
|
echo '.balign STRUCT_ALIGNMENT'; \
|
|
|
|
|
echo ".global $${symbase}_begin"; \
|
|
|
|
|
echo "$${symbase}_begin:"; \
|
|
|
|
|
echo '.incbin "'$$dtb'" '; \
|
|
|
|
|
echo ".global $${symbase}_end"; \
|
|
|
|
|
echo "$${symbase}_end:"; \
|
|
|
|
|
done < $<; \
|
|
|
|
|
} > $@
|
|
|
|
|
|
|
|
|
|
.builtin-dtbs.S: .builtin-dtbs-list FORCE
|
|
|
|
|
$(call if_changed,wrap_dtbs)
|
|
|
|
|
|
|
|
|
|
quiet_cmd_gen_dtbs_list = GEN $@
|
|
|
|
|
cmd_gen_dtbs_list = \
|
|
|
|
|
$(if $(CONFIG_BUILTIN_DTB_NAME), echo "arch/$(SRCARCH)/boot/dts/$(CONFIG_BUILTIN_DTB_NAME).dtb",:) > $@
|
|
|
|
|
|
|
|
|
|
.builtin-dtbs-list: arch/$(SRCARCH)/boot/dts/dtbs-list FORCE
|
|
|
|
|
$(call if_changed,$(if $(CONFIG_BUILTIN_DTB_ALL),copy,gen_dtbs_list))
|
|
|
|
|
|
|
|
|
|
targets += .builtin-dtbs-list
|
|
|
|
|
|
|
|
|
|
ifdef CONFIG_GENERIC_BUILTIN_DTB
|
|
|
|
|
targets += .builtin-dtbs.S .builtin-dtbs.o
|
2025-09-18 10:05:46 +02:00
|
|
|
vmlinux.unstripped: .builtin-dtbs.o
|
2024-09-23 16:56:03 +09:00
|
|
|
endif
|
|
|
|
|
|
2025-09-18 10:05:46 +02:00
|
|
|
# vmlinux.unstripped
|
2024-09-23 16:56:03 +09:00
|
|
|
# ---------------------------------------------------------------------------
|
kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS
include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
as a placeholder.
Genksyms writes the version CRCs into the linker script, which will be
used for filling the __crc_* symbols. The linker script format depends
on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
to the reference of CRC.
It is time to get rid of this complexity.
Now that modpost parses text files (.*.cmd) to collect all the CRCs,
it can generate C code that will be linked to the vmlinux or modules.
Generate a new C file, .vmlinux.export.c, which contains the CRCs of
symbols exported by vmlinux. It is compiled and linked to vmlinux in
scripts/link-vmlinux.sh.
Put the CRCs of symbols exported by modules into the existing *.mod.c
files. No additional build step is needed for modules. As before,
*.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
No linker magic is used here. The new C implementation works in the
same way, whether CONFIG_RELOCATABLE is enabled or not.
CONFIG_MODULE_REL_CRCS is no longer needed.
Previously, Kbuild invoked additional $(LD) to update the CRCs in
objects, but this step is unneeded too.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM-14 (x86-64)
2022-05-13 20:39:22 +09:00
|
|
|
|
2024-10-30 12:38:44 +05:30
|
|
|
ifdef CONFIG_ARCH_WANTS_PRE_LINK_VMLINUX
|
2025-09-18 10:05:46 +02:00
|
|
|
vmlinux.unstripped: arch/$(SRCARCH)/tools/vmlinux.arch.o
|
2024-10-30 12:38:44 +05:30
|
|
|
|
|
|
|
|
arch/$(SRCARCH)/tools/vmlinux.arch.o: vmlinux.o FORCE
|
|
|
|
|
$(Q)$(MAKE) $(build)=arch/$(SRCARCH)/tools $@
|
|
|
|
|
endif
|
|
|
|
|
|
2022-09-28 15:39:41 +09:00
|
|
|
ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(SRCARCH)/Makefile.postlink)
|
|
|
|
|
|
|
|
|
|
# Final link of vmlinux with optional arch pass after final link
|
|
|
|
|
cmd_link_vmlinux = \
|
2025-03-11 12:06:18 +01:00
|
|
|
$< "$(LD)" "$(KBUILD_LDFLAGS)" "$(LDFLAGS_vmlinux)" "$@"; \
|
2022-09-28 15:39:41 +09:00
|
|
|
$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) $@, true)
|
|
|
|
|
|
2025-09-18 10:05:52 +02:00
|
|
|
targets += vmlinux.unstripped .vmlinux.export.o
|
|
|
|
|
vmlinux.unstripped: scripts/link-vmlinux.sh vmlinux.o .vmlinux.export.o $(KBUILD_LDS) FORCE
|
2022-09-28 15:39:41 +09:00
|
|
|
+$(call if_changed_dep,link_vmlinux)
|
2024-11-23 14:33:37 +01:00
|
|
|
ifdef CONFIG_DEBUG_INFO_BTF
|
resolve_btfids: Change in-place update with raw binary output
Currently resolve_btfids updates .BTF_ids section of an ELF file
in-place, based on the contents of provided BTF, usually within the
same input file, and optionally a BTF base.
Change resolve_btfids behavior to enable BTF transformations as part
of its main operation. To achieve this, in-place ELF write in
resolve_btfids is replaced with generation of the following binaries:
* ${1}.BTF with .BTF section data
* ${1}.BTF_ids with .BTF_ids section data if it existed in ${1}
* ${1}.BTF.base with .BTF.base section data for out-of-tree modules
The execution of resolve_btfids and consumption of its output is
orchestrated by scripts/gen-btf.sh introduced in this patch.
The motivation for emitting binary data is that it allows simplifying
resolve_btfids implementation by delegating ELF update to the $OBJCOPY
tool [1], which is already widely used across the codebase.
There are two distinct paths for BTF generation and resolve_btfids
application in the kernel build: for vmlinux and for kernel modules.
For the vmlinux binary a .BTF section is added in a roundabout way to
ensure correct linking. The patch doesn't change this approach, only
the implementation is a little different.
Before this patch it worked as follows:
* pahole consumed .tmp_vmlinux1 [2] and added .BTF section with
llvm-objcopy [3] to it
* then everything except the .BTF section was stripped from .tmp_vmlinux1
into a .tmp_vmlinux1.bpf.o object [2], later linked into vmlinux
* resolve_btfids was executed later on vmlinux.unstripped [4],
updating it in-place
After this patch gen-btf.sh implements the following:
* pahole consumes .tmp_vmlinux1 and produces a *detached* file with
raw BTF data
* resolve_btfids consumes .tmp_vmlinux1 and detached BTF to produce
(potentially modified) .BTF, and .BTF_ids sections data
* a .tmp_vmlinux1.bpf.o object is then produced with objcopy copying
BTF output of resolve_btfids
* .BTF_ids data gets embedded into vmlinux.unstripped in
link-vmlinux.sh by objcopy --update-section
For kernel modules, creating a special .bpf.o file is not necessary,
and so embedding of sections data produced by resolve_btfids is
straightforward with objcopy.
With this patch an ELF file becomes effectively read-only within
resolve_btfids, which allows deleting elf_update() call and satellite
code (like compressed_section_fix [5]).
Endianness handling of .BTF_ids data is also changed. Previously the
"flags" part of the section was bswapped in sets_patch() [6], and then
Elf_Type was modified before elf_update() to signal to libelf that
bswap may be necessary. With this patch we explicitly bswap entire
data buffer on load and on dump.
[1] https://lore.kernel.org/bpf/131b4190-9c49-4f79-a99d-c00fac97fa44@linux.dev/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/link-vmlinux.sh?h=v6.18#n110
[3] https://git.kernel.org/pub/scm/devel/pahole/pahole.git/tree/btf_encoder.c?h=v1.31#n1803
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/link-vmlinux.sh?h=v6.18#n284
[5] https://lore.kernel.org/bpf/20200819092342.259004-1-jolsa@kernel.org/
[6] https://lore.kernel.org/bpf/cover.1707223196.git.vmalik@redhat.com/
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Tested-by: Alan Maguire <alan.maguire@oracle.com>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/bpf/20251219181825.1289460-3-ihor.solodrai@linux.dev
2025-12-19 10:18:25 -08:00
|
|
|
vmlinux.unstripped: $(RESOLVE_BTFIDS) $(srctree)/scripts/gen-btf.sh
|
2024-11-23 14:33:37 +01:00
|
|
|
endif
|
kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS
include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
as a placeholder.
Genksyms writes the version CRCs into the linker script, which will be
used for filling the __crc_* symbols. The linker script format depends
on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
to the reference of CRC.
It is time to get rid of this complexity.
Now that modpost parses text files (.*.cmd) to collect all the CRCs,
it can generate C code that will be linked to the vmlinux or modules.
Generate a new C file, .vmlinux.export.c, which contains the CRCs of
symbols exported by vmlinux. It is compiled and linked to vmlinux in
scripts/link-vmlinux.sh.
Put the CRCs of symbols exported by modules into the existing *.mod.c
files. No additional build step is needed for modules. As before,
*.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
No linker magic is used here. The new C implementation works in the
same way, whether CONFIG_RELOCATABLE is enabled or not.
CONFIG_MODULE_REL_CRCS is no longer needed.
Previously, Kbuild invoked additional $(LD) to update the CRCs in
objects, but this step is unneeded too.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM-14 (x86-64)
2022-05-13 20:39:22 +09:00
|
|
|
|
2025-02-26 21:30:14 +08:00
|
|
|
ifdef CONFIG_BUILDTIME_TABLE_SORT
|
2025-09-18 10:05:46 +02:00
|
|
|
vmlinux.unstripped: scripts/sorttable
|
2025-02-26 21:30:14 +08:00
|
|
|
endif
|
|
|
|
|
|
2025-09-18 10:05:46 +02:00
|
|
|
# vmlinux
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
2025-09-18 10:05:47 +02:00
|
|
|
remove-section-y := .modinfo
|
2025-10-08 15:46:44 -07:00
|
|
|
remove-section-$(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS) += '.rel*' '!.rel*.dyn'
|
2025-10-08 15:46:45 -07:00
|
|
|
# for compatibility with binutils < 2.32
|
|
|
|
|
# https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c12d9fa2afe7abcbe407a00e15719e1a1350c2a7
|
|
|
|
|
remove-section-$(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS) += '.rel.*'
|
2025-09-18 10:05:46 +02:00
|
|
|
|
2025-10-10 14:49:27 -07:00
|
|
|
remove-symbols := -w --strip-unneeded-symbol='__mod_device_table__*'
|
2025-09-18 10:05:51 +02:00
|
|
|
|
2025-09-18 10:05:47 +02:00
|
|
|
# To avoid warnings: "empty loadable segment detected at ..." from GNU objcopy,
|
|
|
|
|
# it is necessary to remove the PT_LOAD flag from the segment.
|
2025-09-18 10:05:46 +02:00
|
|
|
quiet_cmd_strip_relocs = OBJCOPY $@
|
2025-09-18 10:05:47 +02:00
|
|
|
cmd_strip_relocs = $(OBJCOPY) $(patsubst %,--set-section-flags %=noload,$(remove-section-y)) $< $@; \
|
2025-09-18 10:05:51 +02:00
|
|
|
$(OBJCOPY) $(addprefix --remove-section=,$(remove-section-y)) $(remove-symbols) $@
|
2025-09-18 10:05:46 +02:00
|
|
|
|
|
|
|
|
targets += vmlinux
|
|
|
|
|
vmlinux: vmlinux.unstripped FORCE
|
|
|
|
|
$(call if_changed,strip_relocs)
|
|
|
|
|
|
2025-09-18 10:05:48 +02:00
|
|
|
# modules.builtin.modinfo
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
2025-11-05 15:30:27 -07:00
|
|
|
# .modinfo in vmlinux.unstripped is aligned to 8 bytes for compatibility with
|
|
|
|
|
# tools that expect vmlinux to have sufficiently aligned sections but the
|
|
|
|
|
# additional bytes used for padding .modinfo to satisfy this requirement break
|
|
|
|
|
# certain versions of kmod with
|
|
|
|
|
#
|
|
|
|
|
# depmod: ERROR: kmod_builtin_iter_next: unexpected string without modname prefix
|
|
|
|
|
#
|
|
|
|
|
# Strip the trailing padding bytes after extracting .modinfo to comply with
|
|
|
|
|
# what kmod expects to parse.
|
|
|
|
|
quiet_cmd_modules_builtin_modinfo = GEN $@
|
|
|
|
|
cmd_modules_builtin_modinfo = $(cmd_objcopy); \
|
2026-01-28 14:37:51 +08:00
|
|
|
sed -i 's/\x00\+$$/\x00/g' $@; \
|
|
|
|
|
chmod -x $@
|
2025-11-05 15:30:27 -07:00
|
|
|
|
2025-09-18 10:05:48 +02:00
|
|
|
OBJCOPYFLAGS_modules.builtin.modinfo := -j .modinfo -O binary
|
|
|
|
|
|
|
|
|
|
targets += modules.builtin.modinfo
|
|
|
|
|
modules.builtin.modinfo: vmlinux.unstripped FORCE
|
2025-11-05 15:30:27 -07:00
|
|
|
$(call if_changed,modules_builtin_modinfo)
|
2025-09-18 10:05:48 +02:00
|
|
|
|
|
|
|
|
# modules.builtin
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
__default: modules.builtin
|
|
|
|
|
|
|
|
|
|
# The second line aids cases where multiple modules share the same object.
|
|
|
|
|
|
|
|
|
|
quiet_cmd_modules_builtin = GEN $@
|
|
|
|
|
cmd_modules_builtin = \
|
|
|
|
|
tr '\0' '\n' < $< | \
|
|
|
|
|
sed -n 's/^[[:alnum:]:_]*\.file=//p' | \
|
|
|
|
|
tr ' ' '\n' | uniq | sed -e 's:^:kernel/:' -e 's/$$/.ko/' > $@
|
|
|
|
|
|
|
|
|
|
targets += modules.builtin
|
|
|
|
|
modules.builtin: modules.builtin.modinfo FORCE
|
|
|
|
|
$(call if_changed,modules_builtin)
|
|
|
|
|
|
2025-05-12 14:36:58 +09:00
|
|
|
# modules.builtin.ranges
|
kbuild: generate offset range data for builtin modules
Create file module.builtin.ranges that can be used to find where
built-in modules are located by their addresses. This will be useful for
tracing tools to find what functions are for various built-in modules.
The offset range data for builtin modules is generated using:
- modules.builtin: associates object files with module names
- vmlinux.map: provides load order of sections and offset of first member
per section
- vmlinux.o.map: provides offset of object file content per section
- .*.cmd: build cmd file with KBUILD_MODFILE
The generated data will look like:
.text 00000000-00000000 = _text
.text 0000baf0-0000cb10 amd_uncore
.text 0009bd10-0009c8e0 iosf_mbi
...
.text 00b9f080-00ba011a intel_skl_int3472_discrete
.text 00ba0120-00ba03c0 intel_skl_int3472_discrete intel_skl_int3472_tps68470
.text 00ba03c0-00ba08d6 intel_skl_int3472_tps68470
...
.data 00000000-00000000 = _sdata
.data 0000f020-0000f680 amd_uncore
For each ELF section, it lists the offset of the first symbol. This can
be used to determine the base address of the section at runtime.
Next, it lists (in strict ascending order) offset ranges in that section
that cover the symbols of one or more builtin modules. Multiple ranges
can apply to a single module, and ranges can be shared between modules.
The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data
is generated for kernel modules that are built into the kernel image.
How it works:
1. The modules.builtin file is parsed to obtain a list of built-in
module names and their associated object names (the .ko file that
the module would be in if it were a loadable module, hereafter
referred to as <kmodfile>). This object name can be used to
identify objects in the kernel compile because any C or assembler
code that ends up into a built-in module will have the option
-DKBUILD_MODFILE=<kmodfile> present in its build command, and those
can be found in the .<obj>.cmd file in the kernel build tree.
If an object is part of multiple modules, they will all be listed
in the KBUILD_MODFILE option argument.
This allows us to conclusively determine whether an object in the
kernel build belong to any modules, and which.
2. The vmlinux.map is parsed next to determine the base address of each
top level section so that all addresses into the section can be
turned into offsets. This makes it possible to handle sections
getting loaded at different addresses at system boot.
We also determine an 'anchor' symbol at the beginning of each
section to make it possible to calculate the true base address of
a section at runtime (i.e. symbol address - symbol offset).
We collect start addresses of sections that are included in the top
level section. This is used when vmlinux is linked using vmlinux.o,
because in that case, we need to look at the vmlinux.o linker map to
know what object a symbol is found in.
And finally, we process each symbol that is listed in vmlinux.map
(or vmlinux.o.map) based on the following structure:
vmlinux linked from vmlinux.a:
vmlinux.map:
<top level section>
<included section> -- might be same as top level section)
<object> -- built-in association known
<symbol> -- belongs to module(s) object belongs to
...
vmlinux linked from vmlinux.o:
vmlinux.map:
<top level section>
<included section> -- might be same as top level section)
vmlinux.o -- need to use vmlinux.o.map
<symbol> -- ignored
...
vmlinux.o.map:
<section>
<object> -- built-in association known
<symbol> -- belongs to module(s) object belongs to
...
3. As sections, objects, and symbols are processed, offset ranges are
constructed in a straight-forward way:
- If the symbol belongs to one or more built-in modules:
- If we were working on the same module(s), extend the range
to include this object
- If we were working on another module(s), close that range,
and start the new one
- If the symbol does not belong to any built-in modules:
- If we were working on a module(s) range, close that range
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-06 10:45:03 -04:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
ifdef CONFIG_BUILTIN_MODULE_RANGES
|
|
|
|
|
__default: modules.builtin.ranges
|
|
|
|
|
|
|
|
|
|
quiet_cmd_modules_builtin_ranges = GEN $@
|
|
|
|
|
cmd_modules_builtin_ranges = gawk -f $(real-prereqs) > $@
|
|
|
|
|
|
|
|
|
|
targets += modules.builtin.ranges
|
|
|
|
|
modules.builtin.ranges: $(srctree)/scripts/generate_builtin_ranges.awk \
|
|
|
|
|
modules.builtin vmlinux.map vmlinux.o.map FORCE
|
|
|
|
|
$(call if_changed,modules_builtin_ranges)
|
|
|
|
|
|
2025-09-18 10:05:46 +02:00
|
|
|
vmlinux.map: vmlinux.unstripped
|
kbuild: generate offset range data for builtin modules
Create file module.builtin.ranges that can be used to find where
built-in modules are located by their addresses. This will be useful for
tracing tools to find what functions are for various built-in modules.
The offset range data for builtin modules is generated using:
- modules.builtin: associates object files with module names
- vmlinux.map: provides load order of sections and offset of first member
per section
- vmlinux.o.map: provides offset of object file content per section
- .*.cmd: build cmd file with KBUILD_MODFILE
The generated data will look like:
.text 00000000-00000000 = _text
.text 0000baf0-0000cb10 amd_uncore
.text 0009bd10-0009c8e0 iosf_mbi
...
.text 00b9f080-00ba011a intel_skl_int3472_discrete
.text 00ba0120-00ba03c0 intel_skl_int3472_discrete intel_skl_int3472_tps68470
.text 00ba03c0-00ba08d6 intel_skl_int3472_tps68470
...
.data 00000000-00000000 = _sdata
.data 0000f020-0000f680 amd_uncore
For each ELF section, it lists the offset of the first symbol. This can
be used to determine the base address of the section at runtime.
Next, it lists (in strict ascending order) offset ranges in that section
that cover the symbols of one or more builtin modules. Multiple ranges
can apply to a single module, and ranges can be shared between modules.
The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data
is generated for kernel modules that are built into the kernel image.
How it works:
1. The modules.builtin file is parsed to obtain a list of built-in
module names and their associated object names (the .ko file that
the module would be in if it were a loadable module, hereafter
referred to as <kmodfile>). This object name can be used to
identify objects in the kernel compile because any C or assembler
code that ends up into a built-in module will have the option
-DKBUILD_MODFILE=<kmodfile> present in its build command, and those
can be found in the .<obj>.cmd file in the kernel build tree.
If an object is part of multiple modules, they will all be listed
in the KBUILD_MODFILE option argument.
This allows us to conclusively determine whether an object in the
kernel build belong to any modules, and which.
2. The vmlinux.map is parsed next to determine the base address of each
top level section so that all addresses into the section can be
turned into offsets. This makes it possible to handle sections
getting loaded at different addresses at system boot.
We also determine an 'anchor' symbol at the beginning of each
section to make it possible to calculate the true base address of
a section at runtime (i.e. symbol address - symbol offset).
We collect start addresses of sections that are included in the top
level section. This is used when vmlinux is linked using vmlinux.o,
because in that case, we need to look at the vmlinux.o linker map to
know what object a symbol is found in.
And finally, we process each symbol that is listed in vmlinux.map
(or vmlinux.o.map) based on the following structure:
vmlinux linked from vmlinux.a:
vmlinux.map:
<top level section>
<included section> -- might be same as top level section)
<object> -- built-in association known
<symbol> -- belongs to module(s) object belongs to
...
vmlinux linked from vmlinux.o:
vmlinux.map:
<top level section>
<included section> -- might be same as top level section)
vmlinux.o -- need to use vmlinux.o.map
<symbol> -- ignored
...
vmlinux.o.map:
<section>
<object> -- built-in association known
<symbol> -- belongs to module(s) object belongs to
...
3. As sections, objects, and symbols are processed, offset ranges are
constructed in a straight-forward way:
- If the symbol belongs to one or more built-in modules:
- If we were working on the same module(s), extend the range
to include this object
- If we were working on another module(s), close that range,
and start the new one
- If the symbol does not belong to any built-in modules:
- If we were working on a module(s) range, close that range
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-06 10:45:03 -04:00
|
|
|
@:
|
|
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
2024-08-18 16:07:11 +09:00
|
|
|
# Add FORCE to the prerequisites of a target to force it to be always rebuilt.
|
kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS
include/{linux,asm-generic}/export.h defines a weak symbol, __crc_*
as a placeholder.
Genksyms writes the version CRCs into the linker script, which will be
used for filling the __crc_* symbols. The linker script format depends
on CONFIG_MODULE_REL_CRCS. If it is enabled, __crc_* holds the offset
to the reference of CRC.
It is time to get rid of this complexity.
Now that modpost parses text files (.*.cmd) to collect all the CRCs,
it can generate C code that will be linked to the vmlinux or modules.
Generate a new C file, .vmlinux.export.c, which contains the CRCs of
symbols exported by vmlinux. It is compiled and linked to vmlinux in
scripts/link-vmlinux.sh.
Put the CRCs of symbols exported by modules into the existing *.mod.c
files. No additional build step is needed for modules. As before,
*.mod.c are compiled and linked to *.ko in scripts/Makefile.modfinal.
No linker magic is used here. The new C implementation works in the
same way, whether CONFIG_RELOCATABLE is enabled or not.
CONFIG_MODULE_REL_CRCS is no longer needed.
Previously, Kbuild invoked additional $(LD) to update the CRCs in
objects, but this step is unneeded too.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM-14 (x86-64)
2022-05-13 20:39:22 +09:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
PHONY += FORCE
|
|
|
|
|
FORCE:
|
|
|
|
|
|
|
|
|
|
# Read all saved command lines and dependencies for the $(targets) we
|
|
|
|
|
# may be building above, using $(if_changed{,_dep}). As an
|
|
|
|
|
# optimization, we don't need to read them if the target does not
|
|
|
|
|
# exist, we will rebuild anyway in that case.
|
|
|
|
|
|
|
|
|
|
existing-targets := $(wildcard $(sort $(targets)))
|
|
|
|
|
|
|
|
|
|
-include $(foreach f,$(existing-targets),$(dir $(f)).$(notdir $(f)).cmd)
|
|
|
|
|
|
|
|
|
|
.PHONY: $(PHONY)
|