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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox