checking whether modules can be built... * ACCESS DENIED: unlink: /usr/src/linux-4.15.17-gentoo/null.dwo * ACCESS DENIED: fopen_wr: /usr/src/linux-4.15.17-gentoo/null.dwo * ACCESS DENIED: unlink: /usr/src/linux-4.15.17-gentoo/null.dwo yes * ACCESS DENIED: unlink: /usr/src/linux-4.15.17-gentoo/null.dwo * ACCESS DENIED: fopen_wr: /usr/src/linux-4.15.17-gentoo/null.dwo * ACCESS DENIED: unlink: /usr/src/linux-4.15.17-gentoo/null.dwo also see bugs: Reproducible: Always Steps to Reproduce: 1) have kernel configured with CONFIG_DEBUG_INFO_SPLIT=y 2) emerge sys-kernel/spl Actual Results: fails with sandbox violation Expected Results: builds https://bugs.gentoo.org/646640 https://bugs.gentoo.org/647782 workaround is configuring the kernel without CONFIG_DEBUG_INFO_SPLIT
adding addpredict "${KV_OUT_DIR}"/null.dwo somewhere in linux-mod_src_compile() allows the modules to be built, but I'm not sure it's the correct solution.
https://gcc.gnu.org/wiki/DebugFission Use the -gsplit-dwarf option to enable the generation of split DWARF at compile time. This option must be used in conjunction with -c; Fission cannot be used when compiling and linking in the same step. it fails at objcopy step (that's from another package) A: /usr/src/linux-4.15.17-gentoo/null.dwo R: /usr/src/linux-4.15.17-gentoo/null.dwo C: /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/objcopy --extract-dwo /tmp/portage/sys-kernel/it87-9999/temp/cclC5w6T.o null.dwo
--strip-dwo Remove the contents of all DWARF .dwo sections, leaving the remaining debugging sections and all symbols intact. This option is intended for use by the compiler as part of the -gsplit-dwarf option, which splits debug information between the .o file and a separate .dwo file. The compiler generates all debug information in the same file, then uses the --extract-dwo option to copy the .dwo sections to the .dwo file, then the --strip-dwo option to remove those sections from the original .o file. --extract-dwo Extract the contents of all DWARF .dwo sections. See the --strip-dwo option for more information. need to find the reason why it tries to extract to null.dwo into kernel source.
ok I spent some time chasing this thing. human readable summary: to me it looks like then gcc is asked to spit out dwo files, uses objcopy. and objcopy decides to place the files into kernel build directory, which is /lib/modules/${KV_FULL}/build -> /usr/src/${KV_FULL}: just a symlink to source dir. I'm looking right now at which kbuild variable causes that and how to avoid it or redefine the behaviour.
That wasn't the conclusion I came to... GCC is being called with -gsplit-dwarf, but without -c. This causes it to make a temporary .o file (since it is linking too), and put the split dwarf in $PWD/null.dwo Linux's build itself always uses -c. So the question IMO is why module builds are skipping that step...
can no longer reproduce it on new kernels (4.19) but on 4.14 it still triggers sandbox.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f0250f181166b46e1c438da988611911519695a1 commit f0250f181166b46e1c438da988611911519695a1 Author: Patrick McLean <patrick.mclean@sony.com> AuthorDate: 2019-03-15 00:29:01 +0000 Commit: Patrick McLean <chutzpah@gentoo.org> CommitDate: 2019-03-15 00:33:55 +0000 linux-mod.eclass: support DEBUG_INFO_{SPLIT,DWARF4} bug #653286 When CONFIG_DEBUG_INFO_SPLIT and/or CONFIG_DEBUG_INFO_DWARF4 are set, the kernel build system tries to create a null.dwo file in the root of the kernel source directory. This adds an addpredict to prevent this from failing due to a sandbox failure. Acked-by: Thomas Deutschmann <whissi@gentoo.org> Closes: https://bugs.gentoo.org/653286 Signed-off-by: Patrick McLean <chutzpah@gentoo.org> eclass/linux-mod.eclass | 4 ++++ 1 file changed, 4 insertions(+)
