[Bug translator/32458] Systemtap instrumentation module build fails on fc42 6.13.0-0.rc2.20241211gitf92f4749861b.24.fc42
wcohen at redhat dot com
sourceware-bugzilla@sourceware.org
Fri Jan 10 00:25:52 GMT 2025
https://sourceware.org/bugzilla/show_bug.cgi?id=32458
William Cohen <wcohen at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |https://bugzilla.redhat.com
| |/show_bug.cgi?id=2332597
--- Comment #2 from William Cohen <wcohen at redhat dot com> ---
Found the last rawhide kernel that worked and the first rawhide kernel that
failed to build with the reproducer:
stap --poison-cache -p4 -ke 'probe begin {printf("hello\n"); exit()}'
The last working rawhide kernel is
kernel-6.13.0-0.rc0.20241126git7eef7e306d3c.10.fc42
The first broken rawhide kernel is
kernel-6.13.0-0.rc1.20241202gite70140ba0d2b.14.fc42
I was able to build local versions of these twos kernels from the SRPMs. The
problem looked like it was restricted to changes to the kernels Makefile and
files in scripts directory. I did a manual bisections checking out git commits
from linux kernel git repository and copying over the Makefile in the source
top level directory and scripts contents into locally built
kernel-6.13.0-0.rc1.20241202gite70140ba0d2b.14.fc42 source directory. The
transition from working to broken happens between
d17113601909eb43c29cbb3449fd49db427ff6be and
13b25489b6f8bd73ed65f07928f7c27a481f1820.
$ git bisect start 13b25489b6f8bd73ed65f07928f7c27a481f1820
d17113601909eb43c29cbb3449fd49db427ff6be
13b25489b6f8bd73ed65f07928f7c27a481f1820 is the first bad commit
commit 13b25489b6f8bd73ed65f07928f7c27a481f1820
Author: Masahiro Yamada <masahiroy@kernel.org>
Date: Sun Nov 10 10:34:33 2024 +0900
kbuild: change working directory to external module directory with M=
Currently, Kbuild always operates in the output directory of the kernel,
even when building external modules. This increases the risk of external
module Makefiles attempting to write to the kernel directory.
This commit switches the working directory to the external module
directory, allowing the removal of the $(KBUILD_EXTMOD)/ prefix from
some build artifacts.
The command for building external modules maintains backward
compatibility, but Makefiles that rely on working in the kernel
directory may break. In such cases, $(objtree) and $(srctree) should
be used to refer to the output and source directories of the kernel.
The appearance of the build log will change as follows:
[Before]
$ make -C /path/to/my/linux M=/path/to/my/externel/module
make: Entering directory '/path/to/my/linux'
CC [M] /path/to/my/externel/module/helloworld.o
MODPOST /path/to/my/externel/module/Module.symvers
CC [M] /path/to/my/externel/module/helloworld.mod.o
CC [M] /path/to/my/externel/module/.module-common.o
LD [M] /path/to/my/externel/module/helloworld.ko
make: Leaving directory '/path/to/my/linux'
[After]
$ make -C /path/to/my/linux M=/path/to/my/externel/module
make: Entering directory '/path/to/my/linux'
make[1]: Entering directory '/path/to/my/externel/module'
CC [M] helloworld.o
MODPOST Module.symvers
CC [M] helloworld.mod.o
CC [M] .module-common.o
LD [M] helloworld.ko
make[1]: Leaving directory '/path/to/my/externel/module'
make: Leaving directory '/path/to/my/linux'
Printing "Entering directory" twice is cumbersome. This will be
addressed later.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
Documentation/dev-tools/coccinelle.rst | 22 ++++++------------
Documentation/kbuild/makefiles.rst | 14 ++++++++++++
Makefile | 82
++++++++++++++++++++++++++++++++++++++++---------------------------
rust/Makefile | 4 ++--
scripts/Makefile.build | 2 +-
scripts/Makefile.clean | 2 +-
scripts/Makefile.compiler | 2 +-
scripts/Makefile.modpost | 6 ++---
scripts/coccicheck | 6 +----
scripts/nsdeps | 8 +------
scripts/package/install-extmod-build | 7 ++++++
11 files changed, 87 insertions(+), 68 deletions(-)
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the Systemtap
mailing list