libunwind-devel
[Top][All Lists]
Advanced

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

Re: [Libunwind-devel] libunwind on android (UNW_LOCAL_ONLY)


From: Ken Werner
Subject: Re: [Libunwind-devel] libunwind on android (UNW_LOCAL_ONLY)
Date: Wed, 15 Feb 2012 16:01:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0

On 02/14/2012 03:46 PM, Jeff Muizelaar wrote:
On 12-02-13 3:45 AM, Ken Werner wrote:
On 02/13/2012 03:57 AM, Jordan Schidlowsky wrote:
I've been following Ken Werner's work on getting libunwind ported to
the android platform. I was delighted to see an Android.mk on his
branch!

I've followed through the instructions listed here:
https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/LibunwindDebuggerd


I have been trying to get the library built however I've been running
into brick wall after brick wall. Has anyone successfully built the
library and used it locally in a native android application? Any help
would be appreciated.

Hi Jordan,

Local unwinding relies on 'dl_iterate_phdr'- a functionality that
bionic (the libc) doesn't seem to provide[1] to external users. I
think, you'd have to change either bionic or libunwind. In addition,
Android uses a different build system that require you to create an
Android.mk[2].

Just out of curiosity. Why do you need local backtracing on Android
when there's the debuggerd to handle crashes?
I also needed local backtracing on Android for a profiler and did some
work to work around the need for dl_iterate_phdr. That work is up at:
https://github.com/jrmuizel/libunwind/commit/79c42a7cc4d11c90be28bd8bf7cc4884bf8766ce


However, a coworker of mine tried it out and it didn't work for him.
I've not yet had a chance to debug it.

-Jeff

Hi Jeff,

I had a brief look at your code and I guess it just segfaults because the pointer to the ELF image is not initialized and therefore the address of phdr is wrong. However, what the code seems to do is trying to implement dl_iterate_phdr by parsing /proc/<pid>/maps which I suspect is almost impossible to get right (in all corner cases).

Let's take a step back. On ARM Linux the dl_iterate_phdr function is used in case of local unwinding to iterate through the program headers in order to find the start and the end addresses of the ARM specific unwind infos for a given IP. The algorithm looks for all program headers whose type is PT_LOAD and checks if the given IP is in the range of the mapped text segment. If so, it looks for the PT_ARM_EXIDX program header and stores the start and the size of the mapped ARM specific unwind info.

Alternatively this information could be extracted from the ELF header and program headers of ELF file. The file could be identified by parsing /proc/<pid>/maps. Actually quite similar to what src/ptrace/_UPT_find_proc_info.c:get_unwind_info in case of remote unwinding does.

Regards,
Ken



reply via email to

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