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
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
