On Sat, 2025-03-01 at 10:31 +0100, Mathieu Othacehe wrote: > > Hello Richard, > > > You're using this with minidebuginfo so does it not make sense to add > > this as one of the debug sections injected there with the rest of the > > minidebug info? > > Well minidebuginfo is about having compressed symbols in an ELF section, > and keeping .debug_frame is about having unwinding material in another > ELF section. In the end both of them are needed to get human-readable > backtraces on target.
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? > Now, keeping .debug_frame when minidebuginfo is enabled seems a bit > odd. We could only keep .debug_frame on the needed architectures (ARMv7) > and rely on the more generic .eh_frame sections that are never stripped > on other architectures (aarch64, x86_64). Yet, picking what to strip > based on whether minidebuginfo is enabled does not feel right. My point was more that if you're enabling minidebuginfo, you are probably going to want good unwinding information. I'm struggling to see users enabling one without really wanting the other. > Maybe, we could go for a DISTRO_FEATURE that would be even more generic, > such as "backtrace_on_target" that would enable minidebuginfo and keep > the suitable unwinding sections based on the architecture. That way, > users would have unwinding materials and symbols so that GDB, libunwind, > systemd-coredump and other backtracing tools always work on target with > a minimal overhead. People could enable "backtrace_on_target", see if > the image overhead is acceptable to them, and have backtraces without > diving into complex details. > > I think it would still be needed to offer minidebuginfo and > PACKAGE_KEEP_SECTIONS so that users willing to invest more time can > decide precisely what do they want on the target in terms of symbols and > unwinding material. > > What would you think about that? 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? 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 :( Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#212093): https://lists.openembedded.org/g/openembedded-core/message/212093 Mute This Topic: https://lists.openembedded.org/mt/110989612/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
