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. 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. 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? Thanks, Mathieu
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#212091): https://lists.openembedded.org/g/openembedded-core/message/212091 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] -=-=-=-=-=-=-=-=-=-=-=-
