Hello people!
This year we will be having a kernel BoF at Cauldron. It is scheduled for Saturday from 15:30 to 16:30. There will be several kernel maintainers and hackers in attendance, and the goal of the BoF is to discuss and collect feedback about several toolchain-related issues that are of current interest for the kernel. The output of the discussions and the feedback collected will then be used as a basis for further discussions at the Linux Plumbers conference that will be held the next week in Vienna. The idea is to get kernel and toolchain hackers together and advance on these topics. Find below some of the topics we will be discussing. Many of them are relevant to GCC, and we ask you to consider attending if you are coming to the Cauldron. The list of topics is of course not closed, and you are very welcome to bring your own, specially if your work would benefit from feedback from the kernel hackers. - LTO and inline asm symbols A lot of assembler statements reference C symbols, which need to be externally_visible and global for GCC LTO, otherwise they can end up in the wrong asm file and cause missing symbols. Goal of the discussion: Provide an assessment of the reported problem, and discuss the two alternatives already proposed in the bugzillas below: one ad-hoc solution based on parsing symbol references in inline asm strings, another is to allow top-level extended asm that can get input arguments. References: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107779 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045 - "noreturn" and jump tables run-time hints It has been expressed on the kernel side the desire of having the C compiler emit run-time hints marking functions that are not supposed to return and also to provide annotations on jump tables. This is for the benefit of objtool in arm64, see references below. Goal of the discussion: Collect and assess the requirements of these features, discuss their pertinence and the way it could be best implemented. The outcome of the discussion will then be used to continue the discussion with the clang/llvm and kernel hackers at LPC. References: https://lore.kernel.org/linux-arm-kernel/yylmhuxtuanza...@hirez.programming.kicks-ass.net/ - Struct layout randomization (-frandomize-struct-layout) and debug info The GCC plugin hooks in a way that emitted debug info doesn't match with the resulting randomized structs. It works in clang because it generates DWARF later in the compilation process. References: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457 Goal of the discussion: Determine how to best fix this in the plugin, or by using a different approach. The outcome of the discussion will then be used to continue the discussion with the clang/llvm and kernel hackers at LPC. - Userland stack unwinding from within the Linux kernel There are reasons for wanting to unwind both userland and kernel stacks from within the kernel. Currently the kernel can unwind kernel stacks based on ORC (which is revese-engineered from kernel compiled objects by objtool) and userland stacks provided stack frame pointers are present. SFrame is a format similar to ORC, but general enough to be used in userspace, and there is an on-going effort to introduce a SFrame based unwinder in the kernel. This will require some glibc support as well. References: First prototype (V1) from Josh Poimboeuf: https://lkml.kernel.org/lkml/cover.1699487758.git.jpoim...@kernel.org/ - Linking BTF in kernel builds At the moment the BTF used on the kernel side is not directly generated by compilers, but it is instead translated from DWARF by pahole: vmlinux DWARF BTF C module1.ko -------> pahole -------> vmlinux.btf ------> vmlinux.h module2.ko On the BPF program side, however, the BTF is generated directly by the compiler. It has been suggested to get DWARF out of the picture, by having the compiler generating BTF also in the kernel build, and having the BTF linked and deduplicated by the link editor. Note that GCC already supports emitting BTF for targets other than BPF. LLVM currently restricts BTF to the BPF target, but it could be easily adapted to do the same according to the LLVM BPF backend maintainers. Goal of the discussion: Provide an assessment of the proposed approach considering its advantages and possible disadvantages, and kick off the technical discussion on necessary BTF extensions needed that will be then continued at the LPC Toolchains Track. - Potential inter-language LTO issues in kernel Rust code is (as of now provisionally) being added to the Linux kernel. On the other hand the kernel build can be configured to enable LTO when linking vmlinux. Doing LTO involving both C and Rust compiled code allegedly works in clang/llvm. It would be good to check whether it will also work with GCC. Goal of the discussion: Produce a first assessment on the ability of GCC of having compiled objects from different languages linked with LTO. Also, make the GCC Rust people aware of this use case.
