From: Mathieu Othacehe <othacehe@gnu.org>
To: openembedded-core@lists.openembedded.org
Cc: Alexander Kanavin <alex.kanavin@gmail.com>,
Khem Raj <raj.khem@gmail.com>,
Richard Purdie <richard.purdie@linuxfoundation.org>,
Mathieu Othacehe <othacehe@gnu.org>
Subject: [PATCH v3 0/1] lib/oe/package: Add strip keep-section support
Date: Sat, 12 Sep 2026 00:01:37 +0200 [thread overview]
Message-ID: <20260911220138.32414-1-othacehe@gnu.org> (raw)
Hello,
This is v3 of the .debug_frame / keep-section patch, picking back up the
thread from last year:
v1 (PACKAGE_KEEP_DEBUG_FRAME):
https://lists.openembedded.org/g/openembedded-core/message/203797
v2 (PACKAGE_KEEP_SECTIONS):
https://patchwork.yoctoproject.org/project/oe-core/patch/20250204103744.27883-1-othacehe@gnu.org/
Quick recap of the motivation: on 32-bit Arm, GCC's default EHABI unwind
tables (.ARM.exidx / .ARM.extab) don't currently allow libunwind to
produce a full backtrace once execution reaches the C++ termination path
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117941). GCC also emits
DWARF Call Frame Information for the same functions under .debug_frame,
which does allow a complete backtrace, but that section is unconditionally
stripped today. This series lets a recipe opt back in on a per-section
basis via PACKAGE_KEEP_SECTIONS, e.g.:
PACKAGE_KEEP_SECTIONS:pn-myrecipe = ".debug_frame"
What's new in v3:
- Rebased on master, in particular on top of the runstrip() argument
cleanup that landed since v2 -- no more tuple unpacking
- Added an oe-selftest case (package.PackageKeepSections) that builds
core-image-minimal for qemuarm and uses readelf to show busybox loses
.debug_frame by default and keeps it once PACKAGE_KEEP_SECTIONS is set,
per Alexander's request for test coverage on v2.
- A couple of open points from the v2 thread I'd like to address before
this goes further:
* Richard asked whether this should just be folded into minidebuginfo
instead of being a separate "magic" option. minidebuginfo only
injects compressed *symbol* information (.gnu_debugdata); it says
nothing about unwind data. PACKAGE_KEEP_SECTIONS is orthogonal --
you need both symbols and unwind information to get a readable
on-target backtrace, but a user may reasonably want only one of the
two (e.g. GDB against a remote symbol store vs. a fully standalone
coredump). I'd rather keep this as a separate, generic, opt-in knob
than silently grow every minidebuginfo image by ~70KB per Arm binary
that uses C++ exceptions.
* Khem asked whether minidebuginfo could reuse .ARM.exidx/.ARM.extab
the way it uses .eh_frame elsewhere. Per the GCC bug above, those
EHABI tables are exactly the ones that currently produce partial
backtraces on Arm -- that limitation is the reason this series exists.
If that gets fixed on the GCC side, PACKAGE_KEEP_SECTIONS simply
becomes unnecessary for this particular use case, but until then
.debug_frame is the only way to get complete backtraces on 32-bit Arm.
- The matching ref-manual documentation for PACKAGE_KEEP_SECTIONS has been
sent as a separate patch to the docs list.
Mathieu Othacehe (1):
lib/oe/package: Add strip keep-section support
meta/classes-global/staging.bbclass | 4 +-
meta/lib/oe/package.py | 19 +++++++--
meta/lib/oeqa/selftest/cases/package.py | 52 ++++++++++++++++++++++++-
3 files changed, 69 insertions(+), 6 deletions(-)
--
2.34.1
next reply other threads:[~2026-09-11 22:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 22:01 Mathieu Othacehe [this message]
2026-09-11 22:01 ` [PATCH 1/1] lib/oe/package: Add strip keep-section support Mathieu Othacehe
2026-09-12 12:18 ` [OE-core] " Mathieu Dubois-Briand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260911220138.32414-1-othacehe@gnu.org \
--to=othacehe@gnu.org \
--cc=alex.kanavin@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=raj.khem@gmail.com \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.