[PATCH v2 0/3] Fix kernel complementary package installation

[PATCH v2 0/3] Fix kernel complementary package installation

[AdrianF]

From: Adrian Freihofer <adrian.freihofer@siemens.com>

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.

Adrian Freihofer (3):
  kernel.bbclass: make the -src package installable on purpose
  core-image.bbclass: do not pull the kernel -src package in via
    complementary packages
  oe/package.py: copydebugsources: add all kernel source files

 meta/classes-recipe/core-image.bbclass        |  4 +-
 meta/classes-recipe/kernel.bbclass            |  3 +-
 meta/lib/oe/package.py                        | 25 ++++++-
 meta/lib/oeqa/selftest/cases/oelib/package.py | 74 ++++++++++++++++++-
 4 files changed, 98 insertions(+), 8 deletions(-)

-- 
2.55.0

[PATCH v2 1/3] kernel.bbclass: make the -src package installable on purpose

[AdrianF]

From: Adrian Freihofer <adrian.freihofer@siemens.com>

The kernel-source-with-debug-src debug-with-srcpkg split style stashes the
kernel's source under the -src package, but that package was never added
to PACKAGES. It therefore does not exist as an ordinary, installable
package: the only way it ever ends up on an image is through the package
complementary mechanism, which is not suitable for the kernel. Not even
kernel-dbg, which the complementary mechanism is meant for, can be pulled
in that way for the kernel, since IMAGE_INSTALL_COMPLEMENTARY on
*-dbg matches against PN, and the kernel recipe's packages are named after
KERNEL_PACKAGE_NAME rather than PN.

The result was that -src got installed on debug images most likely by
accident, as a side effect of the complementary glob, rather than because
anyone asked for it.

Add -src to PACKAGES when PACKAGE_DEBUG_SPLIT_STYLE is
"debug-with-srcpkg", so it becomes a regular package that can be
requested through IMAGE_INSTALL or RDEPENDS like any other.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
 meta/classes-recipe/kernel.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/kernel.bbclass b/meta/classes-recipe/kernel.bbclass
index 0a6d754108..3c887a5cc5 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -678,7 +678,8 @@ EXPORT_FUNCTIONS do_compile do_transform_kernel do_transform_bundled_initramfs d
 
 # kernel-base becomes kernel-${KERNEL_VERSION}
 # kernel-image becomes kernel-image-${KERNEL_VERSION}
-PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-dbg"
+PACKAGES = "${KERNEL_PACKAGE_NAME} ${KERNEL_PACKAGE_NAME}-base ${KERNEL_PACKAGE_NAME}-vmlinux ${KERNEL_PACKAGE_NAME}-image ${KERNEL_PACKAGE_NAME}-dev ${KERNEL_PACKAGE_NAME}-modules ${KERNEL_PACKAGE_NAME}-dbg \
+    ${@d.getVar('PN') + '-src' if d.getVar('PACKAGE_DEBUG_SPLIT_STYLE') == 'debug-with-srcpkg' else ''}"
 FILES:${PN} = ""
 FILES:${KERNEL_PACKAGE_NAME}-base = "${KERNEL_MODULE_INSTALL_PREFIX}/modules.order ${KERNEL_MODULE_INSTALL_PREFIX}/modules.builtin ${KERNEL_MODULE_INSTALL_PREFIX}/modules.builtin.modinfo"
 FILES:${KERNEL_PACKAGE_NAME}-image = ""
-- 
2.55.0

[PATCH v2 2/3] core-image.bbclass: do not pull the kernel -src package in via complementary packages

[AdrianF]

From: Adrian Freihofer <adrian.freihofer@siemens.com>

IMAGE_INSTALL_COMPLEMENTARY matches complementary packages such as *-src
and *-dbg against PN, but the kernel recipe names its packages after
KERNEL_PACKAGE_NAME rather than PN. That mismatch means kernel-dbg is
never actually installed by the complementary mechanism, while -src
still got pulled in, since it is matched by the generic *-src glob rather
than one keyed off KERNEL_PACKAGE_NAME. So a debug image ended up with
the kernel's -src package in rootfs-dbg, most likely unintentionally,
without the -dbg package it would normally come with.

Add ${PREFERRED_PROVIDER_virtual/kernel}-src to
PACKAGE_EXCLUDE_COMPLEMENTARY so the kernel -src package is no longer
installed automatically like this. Getting kernel debug symbols onto an
image most likely needs a different approach than pulling them into
rootfs or rootfs-dbg via IMAGE_INSTALL_COMPLEMENTARY, which is left for
follow-up work.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
 meta/classes-recipe/core-image.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/core-image.bbclass b/meta/classes-recipe/core-image.bbclass
index 167fa97fd9..a3afca5ebb 100644
--- a/meta/classes-recipe/core-image.bbclass
+++ b/meta/classes-recipe/core-image.bbclass
@@ -74,7 +74,9 @@ IMAGE_FEATURES_REPLACES_ssh-server-openssh = "ssh-server-dropbear"
 # Do not install openssh complementary packages if either packagegroup-core-ssh-dropbear or dropbear
 # is installed # to avoid openssh-dropbear conflict
 # see [Yocto #14858] for more information
-PACKAGE_EXCLUDE_COMPLEMENTARY:append = "${@bb.utils.contains_any('PACKAGE_INSTALL', 'packagegroup-core-ssh-dropbear dropbear', ' openssh', '' , d)}"
+# Do not automatically install e.g. linux-yocto-src but not kernel-dbg
+PACKAGE_EXCLUDE_COMPLEMENTARY:append = "${@bb.utils.contains_any('PACKAGE_INSTALL', 'packagegroup-core-ssh-dropbear dropbear', ' openssh', '' , d)}\
+    ${PREFERRED_PROVIDER_virtual/kernel}-src"
 
 # IMAGE_FEATURES_CONFLICTS_foo = 'bar1 bar2'
 # An error exception would be raised if both image features foo and bar1(or bar2) are included
-- 
2.55.0

[PATCH v2 3/3] oe/package.py: copydebugsources: add all kernel source files

[AdrianF]

From: Adrian Freihofer <adrian.freihofer@siemens.com>

Add all kernel source files to the linux-yocto-src package, not only
the sources from STAGING_KERNEL_DIR.

KERNEL_CC (kernel-arch.bbclass) remaps STAGING_KERNEL_DIR and
STAGING_KERNEL_BUILDDIR to KERNEL_SRC_PATH, overriding CFLAGS own
-ffile-prefix-map for the kernel. copydebugsources() only looks at
CFLAGS to build its prefixmap, so kernel source files recorded under
KERNEL_SRC_PATH were silently dropped. Add prefixmap entries for both
kernel dirs, still destined for TARGET_DBGSRC_DIR.

Also fix oeqa FakeDataStore, which did not support the getVar(name,
expand) signature used by bb.data.inherits_class(), and add a test
covering the kernel-arch recovery path.

Verified by building linux-yocto for qemux86-64: without this fix,
linux-yocto-src only contains 545 files (510 auto-generated *.mod.c
module stubs plus 35 misc .c/.h files compiled outside KERNEL_CC's
remap); with the fix, all 8356 real kernel .c/.h sources recorded
under KERNEL_SRC_PATH are recovered too, for 8901 files total,
including files that only exist under STAGING_KERNEL_BUILDDIR (e.g.
arch/x86/include/generated/asm/syscalls_32.h).

Having all kernel files available is useful for example when debugging
a user space application with the Lauterbach debugger which supports
seamless stepping between user space and kernel space.

Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
---
 meta/lib/oe/package.py                        | 25 ++++++-
 meta/lib/oeqa/selftest/cases/oelib/package.py | 74 ++++++++++++++++++-
 2 files changed, 93 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index b7030643d2..477fa5d5a7 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -979,6 +979,10 @@ def copydebugsources(debugsrcdir, sources, d):
         sdir = d.getVar("S")
         cflags = d.expand("${CFLAGS}")
 
+        # prefixmap maps a host directory to a (match, dest) pair: "match" is
+        # the DWARF-recorded path prefix to select from debugsources.list,
+        # "dest" is the subdirectory under PKGD to copy matches to. For plain
+        # ${CFLAGS}-derived entries these are the same string.
         prefixmap = {}
         for flag in cflags.split():
             if not flag.startswith("-ffile-prefix-map"):
@@ -986,7 +990,20 @@ def copydebugsources(debugsrcdir, sources, d):
             if "recipe-sysroot" in flag:
                 continue
             flag = flag.split("=")
-            prefixmap[flag[1]] = flag[2]
+            prefixmap[flag[1]] = (flag[2], flag[2])
+
+        # kernel-arch.bbclass's KERNEL_CC remaps STAGING_KERNEL_DIR and
+        # STAGING_KERNEL_BUILDDIR to KERNEL_SRC_PATH ("/usr/src/kernel"),
+        # overriding CFLAGS' own mapping for the kernel, so its source files
+        # need a dedicated prefixmap entry to be found, still destined for
+        # TARGET_DBGSRC_DIR like everything else.
+        if bb.data.inherits_class('kernel-arch', d):
+            kernel_src_path = d.getVar('KERNEL_SRC_PATH')
+            target_dbgsrc_dir = d.getVar('TARGET_DBGSRC_DIR')
+            for kernel_dir_var in ('STAGING_KERNEL_DIR', 'STAGING_KERNEL_BUILDDIR'):
+                kernel_dir = d.getVar(kernel_dir_var)
+                if kernel_dir and kernel_src_path and target_dbgsrc_dir:
+                    prefixmap[kernel_dir] = (kernel_src_path, target_dbgsrc_dir)
 
         nosuchdir = []
         basepath = dvar
@@ -1008,9 +1025,9 @@ def copydebugsources(debugsrcdir, sources, d):
                        and not path.endswith((b"<internal>", b"<built-in>"))
                        and b"recipe-sysroot" not in os.path.dirname(path)}
 
-        for pmap, prefix in prefixmap.items():
-            dstroot = dvar + prefix
-            prefix_slash = os.fsencode(prefix) + b"/"
+        for pmap, (match, dest) in prefixmap.items():
+            dstroot = dvar + dest
+            prefix_slash = os.fsencode(match) + b"/"
             relpaths = [path.removeprefix(prefix_slash) for path in sourcepaths
                         if path.startswith(prefix_slash)]
 
diff --git a/meta/lib/oeqa/selftest/cases/oelib/package.py b/meta/lib/oeqa/selftest/cases/oelib/package.py
index 16e13aece9..e78320e6d0 100644
--- a/meta/lib/oeqa/selftest/cases/oelib/package.py
+++ b/meta/lib/oeqa/selftest/cases/oelib/package.py
@@ -17,12 +17,13 @@ class FakeDataStore:
     def __init__(self, values):
         self.values = values
 
-    def getVar(self, name):
+    def getVar(self, name, expand=True):
         return self.values.get(name)
 
     def expand(self, value):
         for name, replacement in self.values.items():
-            value = value.replace("${%s}" % name, replacement)
+            if isinstance(replacement, str):
+                value = value.replace("${%s}" % name, replacement)
         return value
 
 
@@ -270,3 +271,72 @@ class TestCopyDebugSources(TestCase):
             with open(copied_source) as f:
                 self.assertEqual(f.read(), "real\n")
             self.assertFalse(os.path.exists(relocation))
+
+    def test_copydebugsources_recovers_kernel_source_files(self):
+        """Recovers kernel-arch source files recorded outside debugsrcdir.
+
+        kernel-arch recipes remap STAGING_KERNEL_DIR/BUILDDIR to
+        KERNEL_SRC_PATH (typically "/usr/src/kernel") via KERNEL_CC, bypassing
+        CFLAGS entirely, so debugsources.list records kernel files under
+        KERNEL_SRC_PATH rather than under debugsrcdir (typically
+        "/usr/src/debug/...") like every other CFLAGS-derived entry.
+
+        Simulates a kernel-arch recipe with one file coming from each of the
+        two remapped directories (a source file under STAGING_KERNEL_DIR and a
+        generated header under STAGING_KERNEL_BUILDDIR) and asserts
+        copydebugsources() recovers both into the normal debugsrcdir, proving
+        the dedicated kernel-arch prefixmap entries are used instead of (or in
+        addition to) the plain CFLAGS-derived ones.
+        """
+        with tempfile.TemporaryDirectory(prefix="oe-test-package-") as tmpdir:
+            kernel_src_dir = os.path.join(tmpdir, "kernel-source")
+            kernel_build_dir = os.path.join(tmpdir, "kernel-build-artifacts")
+            workdir = os.path.join(tmpdir, "work")
+            pkgd = os.path.join(tmpdir, "pkgd")
+            debugsrcdir = "/usr/src/debug/kernel/1.0"
+            kernel_src_path = "/usr/src/kernel"
+
+            src_rel = os.path.join("arch", "main.c")
+            build_rel = os.path.join("include", "generated", "autoconf.h")
+
+            os.makedirs(os.path.dirname(os.path.join(kernel_src_dir, src_rel)))
+            os.makedirs(os.path.dirname(os.path.join(kernel_build_dir, build_rel)))
+            os.makedirs(workdir)
+            os.makedirs(pkgd)
+
+            src_file = os.path.join(kernel_src_dir, src_rel)
+            build_file = os.path.join(kernel_build_dir, build_rel)
+            with open(src_file, "w") as f:
+                f.write("main\n")
+            with open(build_file, "w") as f:
+                f.write("autoconf\n")
+
+            sources = [
+                os.path.join(kernel_src_path, src_rel),
+                os.path.join(kernel_src_path, build_rel),
+            ]
+            d = FakeDataStore({
+                "WORKDIR": workdir,
+                "PKGD": pkgd,
+                "STRIP": "strip",
+                "OBJCOPY": "objcopy",
+                "S": kernel_src_dir,
+                # KERNEL_CC's own -ffile-prefix-map overrides this for the
+                # kernel, so CFLAGS carries no entry for kernel_src_path.
+                "CFLAGS": "",
+                "__inherit_cache": ["/layer/classes-recipe/kernel-arch.bbclass"],
+                "STAGING_KERNEL_DIR": kernel_src_dir,
+                "STAGING_KERNEL_BUILDDIR": kernel_build_dir,
+                "KERNEL_SRC_PATH": kernel_src_path,
+                "TARGET_DBGSRC_DIR": debugsrcdir,
+            })
+
+            copydebugsources(debugsrcdir, sources, d)
+
+            copied_src = oe.path.join(pkgd, debugsrcdir, src_rel)
+            copied_build = oe.path.join(pkgd, debugsrcdir, build_rel)
+
+            with open(copied_src) as f:
+                self.assertEqual(f.read(), "main\n")
+            with open(copied_build) as f:
+                self.assertEqual(f.read(), "autoconf\n")
-- 
2.55.0

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

[Bruce Ashfield]

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

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

[Freihofer, Adrian]

Hi Bruce

Thank you very much for the detailed response.

On Thu, 2026-10-29 at 16:09 -0700, Bruce Ashfield wrote:
> 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 ?

Yes, that's the use case which triggered this discussion.

But I can think about more use cases which could benefit from a
complete -src package (or different package name) for the kernel as
there are also more use cases for any other -src package.

> 
> 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.

Yes, I can confirm that.

> 
> 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.

Sounds very good.

> 
> 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.

I think this sounds very good and it would address at least the remote
debugging case and make it much more consistent than it is now.


> 
> 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.

Should we then not just drop this patch as well? It's ugly to have this
kernel specific case handled outside of the kernel recipe.

What the kernel recipe could provide instead:
A: an empty -src package (just to behave like all other packages).
B: an empty meta package which RDEPENDS on all the real kernel source
packages. The kernel would no longer be something special. The sources
are also included in the rootfs-dbg by default as for all user space
packages. If the user prefers to have the kernel excluded from rootfs-
dbg he can do what the patch does.

I think B would be the most consistent approach and therefore also the
most self-explanatory implementation.

Thank you very much!
Regards,
Adrian

> 
>  - 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

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

[Bruce Ashfield]

On Thu, Oct 30, 2026 at 6:40 AM Freihofer, Adrian wrote:
>
> > 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 ?
>
> Yes, that's the use case which triggered this discussion.
>
> But I can think about more use cases which could benefit from a
> complete -src package (or different package name) for the kernel as
> there are also more use cases for any other -src package.

Thanks for confirming. I'd like to hear what those other use cases are,
since they're what would drive a full source package (more on that below).

For the host-side case, though, I don't think we need a source package
at all. The debugger runs on the host, so rootfs-dbg only has to supply
the symbols (kernel-dbg, kernel-vmlinux). The source can come from any
tree on the host that matches the build: the build's
work-shared/<machine>/kernel-source, or a linux-yocto checkout at the
recipe's SRCREV. With the prefix map change, every path in the kernel's
debug info is under /usr/src/kernel, so it's a single mapping in the
debugger to that tree.

> >    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.
>
> I think this sounds very good and it would address at least the remote
> debugging case and make it much more consistent than it is now.

Having thought about it more, I'm going to keep linux-source local for
now. The problem is that a full source tree plus the ${B} artifacts is a
superset of kernel-devsrc. Everything devsrc does can be done with it,
just with a bigger footprint. I don't want two copies of the kernel source
to maintain, one curated and one not, and that's what linux-source is.

If a use case arrives that needs the source inside a rootfs (and not just
on the host), I'd want it done inside kernel-devsrc: one tree at
/usr/src/kernel, curated by default as it is today, with an opt-in to
widen it to the full source. No second copy, and no path mapping at all,
since the debug info already points there. The source would need to be
its own package without devsrc's toolchain RDEPENDS, so rootfs-dbg can
take it without pulling in a compiler. And it stays opt-in: nobody should
get ~1.6GB of source by accident.

It also doesn't have to be the whole tree. devsrc is already machine
specific, so the likely way I'd go is a larger devsrc: a curated spine
(core plus the machine's arch), with the drivers it needs discovered
from what the build actually compiled. On qemux86-64 that's about 330MB,
versus 1.5GB for the full tree.

> >  - 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.
>
> Should we then not just drop this patch as well? It's ugly to have this
> kernel specific case handled outside of the kernel recipe.

Agreed, drop it. With the prefix map, linux-yocto-src isn't created at
all, so there's nothing for core-image to exclude. That makes it all three.

The way I see it now, the 592 generated files in linux-yocto-src are the
actual bug today. They're there only because ${B} isn't mapped, and
they're the only reason the kernel gets a -src package. Complementary
install then pulls that package into rootfs-dbg without kernel-dbg, which
is the inconsistency you started from. Fixing the map removes the package,
and so the inconsistency, without any kernel special case in the image
classes or package.py.

> What the kernel recipe could provide instead:
> A: an empty -src package (just to behave like all other packages).
> B: an empty meta package which RDEPENDS on all the real kernel source
> packages. The kernel would no longer be something special. The sources
> are also included in the rootfs-dbg by default as for all user space
> packages. If the user prefers to have the kernel excluded from rootfs-
> dbg he can do what the patch does.
>
> I think B would be the most consistent approach and therefore also the
> most self-explanatory implementation.

I don't think we should do either.

A is an empty package that exists only so the kernel matches a pattern.
It doesn't give anyone anything.

For B, the real source package it would depend on doesn't exist (see
above). Even if it did, B puts the kernel back on the generic
complementary path, which is what I pushed back on in v1:

 - Complementary install maps every installed kernel-module-* package to
   linux-yocto-src, so almost every debug image would get the full kernel
   source by default, about 1.6GB unpacked.

 - It ties linux-yocto to whichever recipe ends up providing the source.

 - kernel-dbg still isn't pulled in by complementary install
   (KERNEL_PACKAGE_NAME vs PN), so you'd still get source without symbols.

The kernel is special here, in that it isn't usually a rootfs package.
I'd rather that be explicit (IMAGE_INSTALL_DEBUGFS for the symbols, and
a mapping to the source on the host) than hidden behind a meta-package.

So my plan is:

 - drop 1/3, 2/3 and 3/3
 - I'll send the kernel.bbclass prefix map change on its own, once I've
   checked SPDX's compiled-sources filter is unaffected (it's the only
   other consumer of the kernel's debugsources list)
 - revisit a full source package, inside kernel-devsrc, when there's a
   concrete use case that needs it in a rootfs

Thougts ?

Bruce

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

[Freihofer, Adrian]

On Fri, 2026-10-30 at 08:17 -0700, Bruce Ashfield wrote:
> On Thu, Oct 30, 2026 at 6:40 AM Freihofer, Adrian wrote:
> > 
> > > 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 ?
> > 
> > Yes, that's the use case which triggered this discussion.
> > 
> > But I can think about more use cases which could benefit from a
> > complete -src package (or different package name) for the kernel as
> > there are also more use cases for any other -src package.
> 
> Thanks for confirming. I'd like to hear what those other use cases
> are,
> since they're what would drive a full source package (more on that
> below).

The longer I'm thinking about that, the more I come to the conclusion
that the use case for the src package is just debugging, profiling,
code coverage and similar development tasks.

Other use cases which need sources have independent ways to find the
sources. For example the SPDX has an independent code path to find the
kernel sources (I checked that). Also the archiver probably has it's
own way (I did not check). But keeping the focus only on bringing the
sources into rootfs or rootfs-dbg is probably right.

> 
> For the host-side case, though, I don't think we need a source
> package
> at all. The debugger runs on the host, so rootfs-dbg only has to
> supply
> the symbols (kernel-dbg, kernel-vmlinux). The source can come from
> any
> tree on the host that matches the build: the build's
> work-shared/<machine>/kernel-source, or a linux-yocto checkout at the
> recipe's SRCREV. With the prefix map change, every path in the
> kernel's
> debug info is under /usr/src/kernel, so it's a single mapping in the
> debugger to that tree.

There are different use cases:
   1. working as a developer on the kernel. For this I agree with your
      statement.
   2. remote debugging a user space application with a debugger such as
      the Trace32 which supports seamless stepping into the kernel
      context of a user space process. For this use case the sources
      are required on the host as for a dynamically linked library
      ideally as a -src and -dbg package.
      As you write bellow, these sources are installed to a path where
      the debug symbols are pointing to in the rootfs-dbg. For the use
      case 1 the sources are in ${S} of the kernel which is different.
   3. Installing the package (also possible with a binary package feed)
      into the rootfs is required for on target debugging and
      profiling. A standard -src package would definitely be useful for
      that (as available on binary distros).

I think from a user's perspective the split into -dev, -dbg, and -src
packages would at least make sense. But it could also be a different
package which provides the source files for the kernel if the standard
way is not feasible from a kernel's perspective. I will come back to
that bellow.

> 
> > >    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.
> > 
> > I think this sounds very good and it would address at least the
> > remote
> > debugging case and make it much more consistent than it is now.
> 
> Having thought about it more, I'm going to keep linux-source local
> for
> now. The problem is that a full source tree plus the ${B} artifacts
> is a
> superset of kernel-devsrc. Everything devsrc does can be done with
> it,
> just with a bigger footprint. I don't want two copies of the kernel
> source
> to maintain, one curated and one not, and that's what linux-source
> is.
> 
> If a use case arrives that needs the source inside a rootfs (and not
> just
> on the host), I'd want it done inside kernel-devsrc: one tree at
> /usr/src/kernel, curated by default as it is today, with an opt-in to
> widen it to the full source. No second copy, and no path mapping at
> all,
> since the debug info already points there. The source would need to
> be
> its own package without devsrc's toolchain RDEPENDS, so rootfs-dbg
> can
> take it without pulling in a compiler. And it stays opt-in: nobody
> should
> get ~1.6GB of source by accident.
> 
> It also doesn't have to be the whole tree. devsrc is already machine
> specific, so the likely way I'd go is a larger devsrc: a curated
> spine
> (core plus the machine's arch), with the drivers it needs discovered
> from what the build actually compiled. On qemux86-64 that's about
> 330MB,
> versus 1.5GB for the full tree.

Practically, I agree and I think it would also address all use cases
which I listed above.

Theoretically, is probably a bit unexpected and therefore requires
documentation which covers that the kernel has a -dev package which
provides what the -dev, -src and -dbg packages usually provide for
other packages.

> 
> > >  - 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.
> > 
> > Should we then not just drop this patch as well? It's ugly to have
> > this
> > kernel specific case handled outside of the kernel recipe.
> 
> Agreed, drop it. With the prefix map, linux-yocto-src isn't created
> at
> all, so there's nothing for core-image to exclude. That makes it all
> three.
> 
> The way I see it now, the 592 generated files in linux-yocto-src are
> the
> actual bug today. They're there only because ${B} isn't mapped, and
> they're the only reason the kernel gets a -src package. Complementary
> install then pulls that package into rootfs-dbg without kernel-dbg,
> which
> is the inconsistency you started from. Fixing the map removes the
> package,
> and so the inconsistency, without any kernel special case in the
> image
> classes or package.py.

Agree. This addresses all use cases by:
 * devtool modify linux-yocto
 * IMAGE_INSTALL_DEBUGFS:append = " kernel-dev"
 * IMAGE_INSTALL:append = " kernel-dev"
 * opkg install kernel-dev

> 
> > What the kernel recipe could provide instead:
> > A: an empty -src package (just to behave like all other packages).
> > B: an empty meta package which RDEPENDS on all the real kernel
> > source
> > packages. The kernel would no longer be something special. The
> > sources
> > are also included in the rootfs-dbg by default as for all user
> > space
> > packages. If the user prefers to have the kernel excluded from
> > rootfs-
> > dbg he can do what the patch does.
> > 
> > I think B would be the most consistent approach and therefore also
> > the
> > most self-explanatory implementation.
> 
> I don't think we should do either.
> 
> A is an empty package that exists only so the kernel matches a
> pattern.
> It doesn't give anyone anything.
> 
> For B, the real source package it would depend on doesn't exist (see
> above). Even if it did, B puts the kernel back on the generic
> complementary path, which is what I pushed back on in v1:
> 
>  - Complementary install maps every installed kernel-module-* package
> to
>    linux-yocto-src, so almost every debug image would get the full
> kernel
>    source by default, about 1.6GB unpacked.
> 
>  - It ties linux-yocto to whichever recipe ends up providing the
> source.
> 
>  - kernel-dbg still isn't pulled in by complementary install
>    (KERNEL_PACKAGE_NAME vs PN), so you'd still get source without
> symbols.
> 
> The kernel is special here, in that it isn't usually a rootfs
> package.
> I'd rather that be explicit (IMAGE_INSTALL_DEBUGFS for the symbols,
> and
> a mapping to the source on the host) than hidden behind a meta-
> package.

Given the size of the kernel source packages and the much more special
use cases which require these source files in practices, I have to
agree. The theory with complementary installation of -src and -dbg is
nice, but problematic for most practical use cases. And it's a fact
that the kernel is different for good reasons.

> 
> So my plan is:
> 
>  - drop 1/3, 2/3 and 3/3
>  - I'll send the kernel.bbclass prefix map change on its own, once
> I've
>    checked SPDX's compiled-sources filter is unaffected (it's the
> only
>    other consumer of the kernel's debugsources list)

I did that a few weeks ago. It's an independent code path.

>  - revisit a full source package, inside kernel-devsrc, when there's
> a
>    concrete use case that needs it in a rootfs

If we have the 9000+ source files instead of only the 400+ generated
files, all use cases which I have in mind are addressed. Sounds good.

> 
> Thougts ?

Thank you very much.
Adrian

> 
> Bruce

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

[Bruce Ashfield]

On Sat, Oct 31, 2026 at 7:22 AM Freihofer, Adrian wrote:
>
> There are different use cases:
>    1. working as a developer on the kernel. For this I agree with your
>       statement.
>    2. remote debugging a user space application with a debugger such as
>       the Trace32 which supports seamless stepping into the kernel
>       context of a user space process. For this use case the sources
>       are required on the host as for a dynamically linked library
>       ideally as a -src and -dbg package.
>    3. Installing the package (also possible with a binary package feed)
>       into the rootfs is required for on target debugging and
>       profiling.

Thanks, that's the list I was looking for. 2 and 3 are the concrete use
cases for having the source in a rootfs (or rootfs-dbg), so I've gone
ahead with it (more below).

> Agree. This addresses all use cases by:
>  * devtool modify linux-yocto
>  * IMAGE_INSTALL_DEBUGFS:append = " kernel-dev"
>  * IMAGE_INSTALL:append = " kernel-dev"
>  * opkg install kernel-dev

One correction (so nobody sees this on the list or in the archive
and copies this into a local.conf): kernel-dev is
System.map, the config and Module.symvers. The source package is
kernel-devsrc, and the symbols are kernel-dbg and kernel-vmlinux.

kernel-devsrc also doesn't cover 2 or 3 today. (At risk of stating
what is already well know) It is what's needed to build modules
(headers, Kconfig/Makefiles, scripts), so it has almost no
.c files, and installing it pulls in the tools for "make scripts prepare"
(bc, bison, flex, gcc-plugins, openssl-dev, ...), which people
don't want in rootfs-dbg.

>  - I'll send the kernel.bbclass prefix map change on its own, once
> I've
>    checked SPDX's compiled-sources filter is unaffected (it's the
> only
>    other consumer of the kernel's debugsources list)
>
> I did that a few weeks ago. It's an independent code path.

Thanks. I read through it as well, and agree, the compiled-sources
filter only matches files found in the kernel-source copy, and the
generated files were never in there.

> If we have the 9000+ source files instead of only the 400+ generated
> files, all use cases which I have in mind are addressed. Sounds good.

That's what I've prototyped, based on some patches that I've had around
for several years at this point .. It stays one package (kernel-devsrc)
and one tree at /usr/src/kernel, where the debug info points with the
prefix map. PACKAGECONFIG chooses what goes in it:

  build:   what kernel-devsrc is today, with its RDEPENDS. The default,
           so nothing changes for existing users.
  source:  a curated core (core directories plus the machine's arch),
           and the drivers the build actually compiled, discovered from
           kbuild's .cmd files. No RDEPENDS.
  full:    the whole tree.
  tarball: the whole tree as a tarball, rather than uncompressed. This
           is similar to what other distros have in their linux-source
	   packages

With:

  PACKAGECONFIG:pn-kernel-devsrc = "source"
  IMAGE_INSTALL_DEBUGFS = "kernel-dbg kernel-vmlinux kernel-devsrc"

on qemux86-64 (7.2.13), rootfs-dbg gets the symbols and 254MB of source
at /usr/src/kernel, and nothing else: no build tools come along. All
9016 source files named in the kernel's debug info are there. The only
ones missing are the 592 generated files from the build directory,
which we don't want to ship. The full tree is 1.5GB.

That covers 2 (rootfs-dbg on the host, no path mapping in the debugger)
and 3 (install it in the image or from a feed). "source build" gives
both the source and what's needed to build modules on target.

The package can optionally be versioned (kernel-devsrc-<kver>, with
kernel-devsrc holding just the /usr/src/kernel link), so the source of
more than one kernel can be installed side by side.

One thing to know: if the image itself already installs kernel-devsrc,
IMAGE_INSTALL_DEBUGFS won't put it in rootfs-dbg. rootfs-dbg starts from
the image's package database, so it's seen as already installed, and
only the debug files are copied over. That's how the debug rootfs works
in general, but it'll need documenting.

If that sounds ok, I'll send the prefix map patch, and then the
kernel-devsrc series as an RFC so you can try it with TRACE32.

Bruce

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

[adrian.freihofer]

On Sun, 2026-11-01 at 17:58 -0800, Bruce Ashfield via openembedded-core
wrote:
> On Sat, Oct 31, 2026 at 7:22 AM Freihofer, Adrian wrote:
> > 
> > There are different use cases:
> >    1. working as a developer on the kernel. For this I agree with
> > your
> >       statement.
> >    2. remote debugging a user space application with a debugger
> > such as
> >       the Trace32 which supports seamless stepping into the kernel
> >       context of a user space process. For this use case the
> > sources
> >       are required on the host as for a dynamically linked library
> >       ideally as a -src and -dbg package.
> >    3. Installing the package (also possible with a binary package
> > feed)
> >       into the rootfs is required for on target debugging and
> >       profiling.
> 
> Thanks, that's the list I was looking for. 2 and 3 are the concrete
> use
> cases for having the source in a rootfs (or rootfs-dbg), so I've gone
> ahead with it (more below).
> 
> > Agree. This addresses all use cases by:
> >  * devtool modify linux-yocto
> >  * IMAGE_INSTALL_DEBUGFS:append = " kernel-dev"
> >  * IMAGE_INSTALL:append = " kernel-dev"
> >  * opkg install kernel-dev
> 
> One correction (so nobody sees this on the list or in the archive
> and copies this into a local.conf): kernel-dev is
> System.map, the config and Module.symvers. The source package is
> kernel-devsrc, and the symbols are kernel-dbg and kernel-vmlinux.
> 
> kernel-devsrc also doesn't cover 2 or 3 today. (At risk of stating
> what is already well know) It is what's needed to build modules
> (headers, Kconfig/Makefiles, scripts), so it has almost no
> .c files, and installing it pulls in the tools for "make scripts
> prepare"
> (bc, bison, flex, gcc-plugins, openssl-dev, ...), which people
> don't want in rootfs-dbg.
> 
> >  - I'll send the kernel.bbclass prefix map change on its own, once
> > I've
> >    checked SPDX's compiled-sources filter is unaffected (it's the
> > only
> >    other consumer of the kernel's debugsources list)
> > 
> > I did that a few weeks ago. It's an independent code path.
> 
> Thanks. I read through it as well, and agree, the compiled-sources
> filter only matches files found in the kernel-source copy, and the
> generated files were never in there.
> 
> > If we have the 9000+ source files instead of only the 400+
> > generated
> > files, all use cases which I have in mind are addressed. Sounds
> > good.
> 
> That's what I've prototyped, based on some patches that I've had
> around
> for several years at this point .. It stays one package (kernel-
> devsrc)
> and one tree at /usr/src/kernel, where the debug info points with the
> prefix map. PACKAGECONFIG chooses what goes in it:
> 
>   build:   what kernel-devsrc is today, with its RDEPENDS. The
> default,
>            so nothing changes for existing users.
>   source:  a curated core (core directories plus the machine's arch),
>            and the drivers the build actually compiled, discovered
> from
>            kbuild's .cmd files. No RDEPENDS.
>   full:    the whole tree.
>   tarball: the whole tree as a tarball, rather than uncompressed.
> This
>            is similar to what other distros have in their linux-
> source
> 	   packages
> 
> With:
> 
>   PACKAGECONFIG:pn-kernel-devsrc = "source"
>   IMAGE_INSTALL_DEBUGFS = "kernel-dbg kernel-vmlinux kernel-devsrc"
> 
> on qemux86-64 (7.2.13), rootfs-dbg gets the symbols and 254MB of
> source
> at /usr/src/kernel, and nothing else: no build tools come along. All
> 9016 source files named in the kernel's debug info are there. The
> only
> ones missing are the 592 generated files from the build directory,
> which we don't want to ship. The full tree is 1.5GB.
> 
> That covers 2 (rootfs-dbg on the host, no path mapping in the
> debugger)
> and 3 (install it in the image or from a feed). "source build" gives
> both the source and what's needed to build modules on target.
> 
> The package can optionally be versioned (kernel-devsrc-<kver>, with
> kernel-devsrc holding just the /usr/src/kernel link), so the source
> of
> more than one kernel can be installed side by side.
> 
> One thing to know: if the image itself already installs kernel-
> devsrc,
> IMAGE_INSTALL_DEBUGFS won't put it in rootfs-dbg. rootfs-dbg starts
> from
> the image's package database, so it's seen as already installed, and
> only the debug files are copied over. That's how the debug rootfs
> works
> in general, but it'll need documenting.

Just a note: There is also the image-combined-dbg.bbclass which merges
all together into rootfs-dbg where ever the package installs it. So,
having it only once installed is fine.

> 
> If that sounds ok, I'll send the prefix map patch, and then the
> kernel-devsrc series as an RFC so you can try it with TRACE32.

This sounds very good. Thank you!

Adrian

> 
> Bruce
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#249173):
> https://lists.openembedded.org/g/openembedded-core/message/249173
> Mute This Topic: https://lists.openembedded.org/mt/121400004/4454582
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe:
> https://lists.openembedded.org/g/openembedded-core/unsub [
> adrian.freihofer@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-