Re: [OE-core] [PATCH v2 0/3] Fix kernel complementary package installation

[Bruce Ashfield <bruce.ashfield@gmail.com>]

On Wed, Sep 23, 2026 at 4:51 PM Adrian Freihofer wrote:
>
> Changes in comparison to v1: Completely different approach
> - Complementary package installation for kernel sources is disabled
> - The linux-yocto-src package can now be installed as a regular package which
>   was not possible before.
> - Additionally, the kernel source files are now correctly included in the
>   linux-yocto-src package.

Sorry for the delay on this, I wanted to actually build and measure
before replying, since this is in master-next.

First, to make sure I have the use case right: this is TRACE32 (or
cross-gdb to qemu, it's a similar pattern) running on the host, with
rootfs-dbg extracted on the host as the debug sysroot. Nothing here runs
gdb on the target. Correct ?

As I said on IRC, I don't want a kernel -src package. It's a second copy
of the kernel tree that you can't build against, and the generic -src
machinery is the wrong tool for the kernel. But I'm not saying no to the
goal. I looked at why linux-yocto-src exists at all, and I think there's
a simpler way to get you there.

Where the kernel's debug info points today (7.2.13, qemux86-64):

  recorded root                      files   what they are
  /usr/src/kernel/                    9016   real source
  /usr/src/debug/linux-yocto/<PV>/     592   generated in ${B}

kernel-arch's KERNEL_CC maps STAGING_KERNEL_DIR and
STAGING_KERNEL_BUILDDIR to /usr/src/kernel, but not ${B}, where the
kernel actually builds. ${B} falls through to the generic debug prefix
map, and those 592 generated files are the only content of
linux-yocto-src. Everything real is already recorded under
/usr/src/kernel.

Are the 592 needed for debugging ? I went through them (with
grep and some AI help):

  files                                     count  content                  regenerable from source?
  *.mod.c                                     557  modinfo boilerplate      no (needs module objects + modpost)
  .vmlinux.export.c                             1  export table             no (needs vmlinux.o)
  vdso32/64-image.c                             2  vdso byte arrays         no (needs the vdso build)
  *.asn1.[ch]                                  14  ASN.1 decoder tables     yes
  capflags.c, inat-tables.c, crc32table.h,
  raid6 tables.c, consolemap_deftbl.c,
  defkeymap.c, ucs_*_table.h,
  oid_registry_data.c, shipped-certs.c,
  gen-kdb_cmds.c, syscalls_{32,64}.h           14  data tables              yes
  raid6 int{1,2,4,8}.c                          4  code (awk-unrolled)      yes

Only the raid6 int*.c files are code that you'd ever step through. A
debugger missing a file just shows no source for that frame. What's
useful can be regenerated by kbuild from the source (as a prerequisite
of the .o), and what can't be regenerated isn't useful. So I don't want
to package any of them. Shipping build output that can be regenerated
can lead to QA issues with mixed arches.

So, what I'm prototyping instead (and have tested):

1) kernel.bbclass:

     KERNEL_CC:append = " -ffile-prefix-map=${B}=${KERNEL_SRC_PATH}"

   All 9608 debug source paths are now under /usr/src/kernel.
   copydebugsources() finds nothing for the -src package, so
   linux-yocto-src isn't created at all. There's no special case in
   package.py. A generated file regenerated in the tree lands exactly
   where the debug info expects it.

   I did an A/B of the kernel built with and without it. In the loaded
   vmlinux sections and the 557 modules, the only differing bytes are
   the build-ids (vmlinux, the embedded vdso note, the modules) and the
   .gnu_debuglink CRC. That is expected, since both hash the debug info,
   which is what changed. There are no code or data changes.

2) For the source itself, I have been carrying an optional linux-source
   package in kernel-devsrc for a long time. It's off by default
   (PACKAGECONFIG), a full source tree at /usr/src/linux-source-<kver>,
   and it doesn't overlap with devsrc (which stays the curated, buildable
   subset). With:

     IMAGE_INSTALL_DEBUGFS = "kernel-dbg kernel-vmlinux linux-source"

   rootfs-dbg has the vmlinux and module .debug files plus the source.
   The debugger maps /usr/src/kernel to /usr/src/linux-source (TRACE32
   has source path translation for this).

   I'm not completely sold on sending this one yet, but I could be
   convinced to go that way rather than a -src package. If it covers
   your use case, that's the argument that would do it.

On the series:

 - 1/3: I'd drop it. With (1) there's no kernel -src package to make
   installable. Assuming I haven't screwed up the logic or misunderstood
   something.

 - 2/3: fine with me. Keeping the kernel out of the complementary
   install is what I asked for in v1, and with (1) it is a no-op.

 - 3/3: I'd drop it. It selects files by their recorded /usr/src/kernel
   path, but installs them under /usr/src/debug/linux-yocto/<PV>, so the
   debugger still needs a path substitution. That's the same cost as
   mapping to a source package. It also duplicates the whole tree (your
   8901 files) into a package that can't be built against. And it
   applies to every kernel-arch recipe (module-base, so out-of-tree
   modules, perf and make-mod-scripts), not just the kernel, so they all
   start carrying kernel sources in their -src packages.

   The linux-source package in (2) is what I'd propose in its place.
   It covers the same need (the full kernel source in rootfs-dbg), but
   it's opt-in, it's a single copy for the kernel only, it carries no
   generated files, and it isn't a -src package at all.

Richard: since 1/3 and 3/3 are in master-next, I'd ask that they be held
while we sort this out.

Two oe-core issues I hit along the way, which I'll report separately:

 - IMAGE_INSTALL_DEBUGFS installs with attempt_only, so a package that
   can't be installed is silently skipped. I hit this with a file
   dependency on a usrmerge distro.

 - An on-target postinst from a debugfs-only package leaks into the main
   rootfs postinst handling and fails do_rootfs.

If this direction works for you, I can send (1) and the linux-source
package as an RFC so you can try it with TRACE32.

Bruce