libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libunwind-devel] Help please with debugging DWARF unwinding on ARM


From: Ben Avison
Subject: [Libunwind-devel] Help please with debugging DWARF unwinding on ARM
Date: Thu, 29 Jun 2017 01:56:06 +0100
User-agent: Opera Mail/1.0 (MacIntel)

Hi all,

First a quick typo to report: at src/dwarf/Gparser.c:281, the memcpy()
statement is lacking a trailing semicolon - this doesn't become apparent
until you enable debugging.

I have previously used libunwind successfully as the backend for
gperftools, however I just get segfaults with the latest version.

Some background: I'm running on ARM, and I configure libunwind with
--enable-debug-frame then run the executable with UNW_ARM_UNWIND_METHOD=1
to force DWARF unwinding.

The revision in git which introduced the bug is 25413c7 (dwarf: Improve
support for binaries missing the GNU_EH_FRAME segment).

Ultimately, the segfault is triggered at the end of fetch_proc_info() where
c->pi is uninitialised when it tried to dereference it. However, I'm having
a hard time understanding the code well enough to know how to ensure it is
initialised correctly.

Gperftools always starts skipping through the call stack from an initial
cursor position set up by unw_init_local(). The very first call to
unw_step() is the one that fails.

If I back out the changes from that git revision, the pi struct is
initialised towards the end of dwarf_extract_proc_info_from_fde(), which is
called from dwarf_search_unwind_table(), in the second such call from
dwarf_find_proc_info().

But using the head of git, dwarf_find_proc_info() exits early because
cb_data.single_fde is set, so it never calls dwarf_search_unwind_table().
single_fde is only set in one place, in dwarf_callback() - in a bit of code
that was never previously called when no .eh_frame_hdr section is found
(which appears to be true in my case). However, if single_fde is set then
control flow has unavoidably also passed through linear_search(), which
also calls dwarf_extract_proc_info_from_fde().

It appears to me that the problem is that sometimes, the first time
dwarf_extract_proc_info_from_fde() is called for a given pi struct, it is
called with need_unwind_info=0, but then dwarf_find_proc_info() is later
called with need_unwind_info=1 but due to single_fde being set, we never
get the pi struct initialised by anyone.

It's possible I've got the wrong end of the stick here, but I'm also far
from sure what the best way to fix this is. Any advice gratefully received!
Please bear in mind I have rather limited working knowledge of the DWARF
spec.

Thanks in advance,
Ben



reply via email to

[Prev in Thread] Current Thread [Next in Thread]