This is the mail archive of the
mailing list for the elfutils project.
Re: Using libdw to get symbol names inside signal handler
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Fri, 01 Apr 2016 15:34:28 +0200
- Subject: Re: Using libdw to get symbol names inside signal handler
On Fri, 2016-04-01 at 11:38 +0000, marko(a)kevac.org wrote:
> I would like to user libunwind and libdw to get backtrace and symbol names
> for backtrace from inside SIGSEGV signal handler.
> I understand that libdw does not have documentation at all, so I am looking
> for help here.
It does have documentation, but it is indeed not as full as we would
like. Please take a look at libdw.h and libdwfl.h
> Is it good decision to use libunwind and libdw for getting backtrace from
> inside signal handler?
> Is libdw async signal safe?
You don't need libunwind for unwinding, you can use the
dwfl_frame_thread calls part of libdw described in libdwfl.h for that.
libdwfl is not designed to be signal safe and it wasn't originally
designed as an in-process unwinder. But people have used it for that.
You might want to take a look at the work of Ben Gamari done a couple of
months back on this mailinglist in a thread with the subject "Using dwfl
to enumerate frames of current thread".
If you really need an in-process unwinder then I would recommend you
take a look at the libbacktrace from the GCC project:
If you just want to get a good backtrace when you get a SIGSEGV or other
fatal signal it makes sense to just call eu-stack -P TID on yourself.
fork and exec are signal safe. And then you don't have to try to deal
with a possibly corrupt program.