[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:


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 and, 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

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 (I didn't come up with a better name yet):
  AC_MSG_CHECKING([whether to build libunwind-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]) ;;
  AM_CONDITIONAL([PTRACE_ONLY], [test x${ptrace_only} = xyes])
  if test x$ptrace_only = xyes; then


reply via email to

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