Openembedded Core Discussions
 help / color / mirror / Atom feed
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



             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