[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] libunwind-ptrace and UNW_REMOTE_ONLY
From: |
Ken Werner |
Subject: |
Re: [Libunwind-devel] libunwind-ptrace and UNW_REMOTE_ONLY |
Date: |
Thu, 10 Nov 2011 16:31:57 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 |
On 11/09/2011 08:15 PM, Arun Sharma wrote:
On Tue, Nov 8, 2011 at 9:46 AM, Ken Werner<address@hidden> wrote:
Hi,
I noticed that for unwinding via DWARF debug frames libunwind-ptrace relies on
the local_addr_space [1] which is not initialized in case of UNW_REMOTE_ONLY
[2]. This leads to a segfault in case CONFIG_DEBUG_FRAME is defined. So, I'm
wondering if there is a nice way to fix this. As a workaround I defined the
local_addr_space even if UNW_REMOTE_ONLY is defined and set the find_proc_info,
resume, and put_unwind_info accessors to NULL. Any suggestions are appreciated.
libunwind-ptrace should not be compiled for REMOTE_ONLY case.
>
I recall you had a question about using UNW_REMOTE_ONLY to deal with
android. Reading through Makefile.am and configure.in, the correct way
to configure for the remote only case is to use "host != target".
If you're trying to work around compilation failures due to the lack
of dl_iterate_phdr on the target, we should find a different
mechanism.
Since libunwind-ptrace sits on top of libunwind remote interface I
thought it's just natural to have it available in case of
UNW_REMOTE_ONLY. I agree that the build system currently doesn't include
libunwind-ptrace. So the question is, do we want a vehicle that allows
users to only build the remote unwinding functionality including
libunwind-ptrace? Probably the least intrusive way to achieve this would
be to add a configure switch that enables UNW_REMOTE_ONLY plus another
define that covers libunwind-ptrace [*].
In case we want libunwind-ptrace to support unwinding via DWARF debug
framed the issue with the address space remains. When libunwind-ptrace
calls the dwarf code the address space is not specified but assumed to
be the local_addr_space. This is perfectly valid for the memory
accessors because the unwinding process mmaps the elf image to extract
the unwind info - thus local.
[*] add something like this in configure.in (I didn't come up with a
better name yet):
AC_MSG_CHECKING([whether to build libunwind-ptrace only])
AC_ARG_ENABLE([ptrace_only],
[ --enable-ptrace-only Build libunwind-ptrace only],
[case "${enableval}" in
yes) ptrace_only=yes ;;
no) ptrace_only=no ;;
*) AC_MSG_ERROR([bad value ${enableval} for --enable-ptrace-only]) ;;
esac],[ptrace_only=no])
AM_CONDITIONAL([PTRACE_ONLY], [test x${ptrace_only} = xyes])
if test x$ptrace_only = xyes; then
CPPFLAGS="${CPPFLAGS} -DUNW_PTRACE_ONLY -DUNW_REMOTE_ONLY"
fi
AC_MSG_RESULT([${ptrace_only}])
Regards
Ken