[CAULDRON] Topics for the Toolchain and Linux kernel BoF

[Jose E. Marchesi]

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.  Some of the topics
may be relevant to GDB, 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/YyLmhUxTUaNzaieC@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.jpoimboe@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.