From: Mathieu Othacehe <othacehe@gnu.org>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org,
Quentin Schulz <quentin.schulz@cherry.de>
Subject: Re: [OE-core] [PATCH v2] lib/oe/package: Add strip keep-section support
Date: Thu, 06 Mar 2025 08:34:52 +0100 [thread overview]
Message-ID: <8734fq8vdv.fsf@gnu.org> (raw)
In-Reply-To: <0a146fbccc15be5f79f2cfdf668da2fdf5ad400e.camel@linuxfoundation.org> (Richard Purdie's message of "Sat, 01 Mar 2025 09:57:48 +0000")
Hello Richard,
> I think the name has been misleading me as I imagined minidebuginfo as
> a small subset of the main debug information rather than just the
> symbols. You're saying it is just the symbols and there is no way to
> extend the compressed information?
The minidebuginfo symbols are stored in:
--8<---------------cut here---------------start------------->8---
subprocess.check_call([objcopy, '--add-section', '.gnu_debugdata={}.xz'.format(minidebugfile), file])
--8<---------------cut here---------------end--------------->8---
the .gnu_debugdata ELF section. That's a convention and some tools out
there (GDB, libunwind) will search for symbols in that specific section.
> OE is about choice but I'm still thinking that if someone enables
> minidebuginfo, they are most likely expecting stack traces to work as
> otherwise the extra symbol information isn't much use. Am is missing
> some key usage?
Another usage would be to debug a live program on target with GDB. You
need the symbols but not necessarily the unwind information to do that I
guess.
> If PACKAGE_KEEP_SECTIONS worked well for all targets, I think I'd be
> happier to consider it but the problem is that it is all very
> architecture dependent :(
Would it be OK if I send a v3 that re-introduces
PACKAGE_KEEP_DEBUG_FRAME, and enables that one if minidebuginfo is
enabled and the target architecture is ARM?
Thanks,
Mathieu
next prev parent reply other threads:[~2025-03-06 7:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-04 10:37 [PATCH v2] lib/oe/package: Add strip keep-section support Mathieu Othacehe
2025-02-04 11:37 ` [OE-core] " Alexander Kanavin
2025-02-04 11:39 ` Alexander Kanavin
2025-02-04 12:36 ` Mathieu Othacehe
2025-02-04 12:50 ` Alexander Kanavin
2025-02-04 14:25 ` Mathieu Othacehe
2025-02-04 19:02 ` Alexander Kanavin
2025-02-27 15:28 ` Richard Purdie
2025-02-28 9:09 ` Mathieu Othacehe
2025-02-28 10:37 ` Richard Purdie
2025-03-01 9:31 ` Mathieu Othacehe
2025-03-01 9:57 ` Richard Purdie
2025-03-06 7:34 ` Mathieu Othacehe [this message]
2025-03-01 16:11 ` Khem Raj
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=8734fq8vdv.fsf@gnu.org \
--to=othacehe@gnu.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=quentin.schulz@cherry.de \
--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.