Re: [systemd-devel] systemd-coredump stack traces
Thanks. Adding libdw as dependency does get the stack traces working. From: Richard Purdie Sent: Friday, August 11, 2023 3:57 AM To: Lennart Poettering ; Aaron Brice Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] systemd-coredump stack traces [You don't often get email from richard.pur...@linuxfoundation.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On Fri, 2023-08-11 at 12:34 +0200, Lennart Poettering wrote: > On Do, 10.08.23 20:34, Aaron Brice (aaron.br...@nikolamotor.com) wrote: > > > I am trying to enable stack traces for core dumps with > > systemd-coredump. I have a yocto build for aarch64 containing > > systemd 250 with the coredump and elfutils options enabled in the > > build, and the binaries I'm trying to debug are not stripped. > > coredumpctl list shows the core files and I can use coredumpctl gdb > > to get a backtrace, but coredumpctl info does not show a backtrace. > > Is there another build option I need, or any good way to debug where > > the stack trace is failing? > > Note that systemd-coredump doesn't directly link against libdw.so.1 > (i.e. the relevant library from elfutils) but will dlopen() it. I > don't know yocto, but I wouldn#t be surprised if it doesn't realize > this and doesn't install the .so in your image (or in your initrd) > because it doesn't notice the dependency. It won't detect that. You probably need to add something like: RDEPENDS:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'coredump', '', 'libdw'}" and a patch for that should really be sent for the recipe in oe-core. > > And if I get it working, does the systemd stacktrace functionality > > support using a -dbg package with debug symbols in a separate file? > > I don't know what yocto -dbg packages are. But the elfutils library > supports the usual debug symbols linux distros provide, including the > minimal debug info available in current fedora distros built-in. We split the binaries/libraries into two pieces to separate out the debug symbols and put the appropriate gnu_debuglink section in place. The debug pieces go into -dbg packages. It is all done with the usual standards so should just work when they're installed or a debuginfod server is running/available. Cheers, Richard
Re: [systemd-devel] systemd-coredump stack traces
On Fri, 2023-08-11 at 12:34 +0200, Lennart Poettering wrote: > On Do, 10.08.23 20:34, Aaron Brice (aaron.br...@nikolamotor.com) wrote: > > > I am trying to enable stack traces for core dumps with > > systemd-coredump. I have a yocto build for aarch64 containing > > systemd 250 with the coredump and elfutils options enabled in the > > build, and the binaries I'm trying to debug are not stripped. > > coredumpctl list shows the core files and I can use coredumpctl gdb > > to get a backtrace, but coredumpctl info does not show a backtrace. > > Is there another build option I need, or any good way to debug where > > the stack trace is failing? > > Note that systemd-coredump doesn't directly link against libdw.so.1 > (i.e. the relevant library from elfutils) but will dlopen() it. I > don't know yocto, but I wouldn#t be surprised if it doesn't realize > this and doesn't install the .so in your image (or in your initrd) > because it doesn't notice the dependency. It won't detect that. You probably need to add something like: RDEPENDS:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'coredump', '', 'libdw'}" and a patch for that should really be sent for the recipe in oe-core. > > And if I get it working, does the systemd stacktrace functionality > > support using a -dbg package with debug symbols in a separate file? > > I don't know what yocto -dbg packages are. But the elfutils library > supports the usual debug symbols linux distros provide, including the > minimal debug info available in current fedora distros built-in. We split the binaries/libraries into two pieces to separate out the debug symbols and put the appropriate gnu_debuglink section in place. The debug pieces go into -dbg packages. It is all done with the usual standards so should just work when they're installed or a debuginfod server is running/available. Cheers, Richard
Re: [systemd-devel] systemd-coredump stack traces
On Do, 10.08.23 20:34, Aaron Brice (aaron.br...@nikolamotor.com) wrote: > I am trying to enable stack traces for core dumps with > systemd-coredump. I have a yocto build for aarch64 containing > systemd 250 with the coredump and elfutils options enabled in the > build, and the binaries I'm trying to debug are not stripped. > coredumpctl list shows the core files and I can use coredumpctl gdb > to get a backtrace, but coredumpctl info does not show a backtrace. > Is there another build option I need, or any good way to debug where > the stack trace is failing? Note that systemd-coredump doesn't directly link against libdw.so.1 (i.e. the relevant library from elfutils) but will dlopen() it. I don't know yocto, but I wouldn#t be surprised if it doesn't realize this and doesn't install the .so in your image (or in your initrd) because it doesn't notice the dependency. > And if I get it working, does the systemd stacktrace functionality > support using a -dbg package with debug symbols in a separate file? I don't know what yocto -dbg packages are. But the elfutils library supports the usual debug symbols linux distros provide, including the minimal debug info available in current fedora distros built-in. Lennart -- Lennart Poettering, Berlin
[systemd-devel] systemd-coredump stack traces
I am trying to enable stack traces for core dumps with systemd-coredump. I have a yocto build for aarch64 containing systemd 250 with the coredump and elfutils options enabled in the build, and the binaries I'm trying to debug are not stripped. coredumpctl list shows the core files and I can use coredumpctl gdb to get a backtrace, but coredumpctl info does not show a backtrace. Is there another build option I need, or any good way to debug where the stack trace is failing? And if I get it working, does the systemd stacktrace functionality support using a -dbg package with debug symbols in a separate file? Thanks, Aaron