All of lore.kernel.org
 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 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.