如何在Android平台上的可执行文件中使用CallStack(在CallStack.tpp中)?

car*_*arl 3 linux android callstack build stack-trace

来自/sf/answers/802692831/的问题

我的最终目标是转储用户空间堆栈。

我尝试将以下cpp文件构建为android平台上的可执行文件。因此,通过调用tryToGetStack(),可以在运行时获取可执行文件的调用堆栈。

#include <utils/CallStack.h>
namespace android
{
    extern "C" void tryToGetStack()
    {
        CallStack stack;
        stack.update();
        stack.dump("");
    }
}
Run Code Online (Sandbox Code Playgroud)

并将lib设置添加到Android.mak,因为CallStack.tpp在libutils中

LOCAL_SHARED_LIBRARIES + = libutils

但是我总是收到错误消息:

错误:未定义对“ android :: CallStack :: CallStack()”的引用

错误:未定义对“ android :: CallStack :: update(int,int)”的引用

...

似乎可执行文件在链接时解析符号,而不是在运行时加载.so文件?我会丢失某些东西还是Android构建系统存在某些限制吗?

我知道这是一个简单的问题,但我确实需要帮助...

更新1

我尝试将代码添加到另一个可执行文件中。结果是一样的...有人知道android构建系统的规则吗?

更新2

我的控制台中有一些关键字“ target StaticExecutable:...”,我认为这就是答案。

http://en.wikipedia.org/wiki/Static_executable

car*_*arl 6

我的最终目标是转储用户空间堆栈

谷歌从互联网上获取了如此多的信息后,我发现有4种方法:

  1. ptracehttp://en.wikipedia.org/wiki/Ptrace

    使用ptrace真的很难,我们需要在使用ptrace附加之前停止线程。

  2. _unwind_backtrace:CallStack使用的方式(CallStack.cpp中的CallStack类)

    示例:http//git.stlinux.com/?p = stm / uclibc.git; a = blob; f = libubacktrace / sysdeps / sh / backtrace.c; h = 18b91b1bb3fa26344a521927c631553a410fcf56; hb = d6a3d9ece5922a337800a8e2ed4db7e226

    它有一个缺点:如果您在线程处理信号时使用它,它将转储信号堆栈而不是转储线程堆栈

    同样的问题:如何在SIGSEGV上使用_Unwind_Backtrace获取fullstacktrace

  3. backtracehttp : //www.gnu.org/software/libc/manual/html_node/Backtraces.html

    GNU扩展功能,无法在Android使用的Bionic libc中实现

    参考:https : //stackoverflow.com/a/8295238/1442443

    参考:http : //lists.puredata.info/pipermail/pd-list/2012-02/094258.html

  4. 转储用户空间线程堆栈的补丁http : //www.gossamer-threads.com/lists/linux/kernel/1525096

    但只能在X86架构中实现... orz

    我尝试将其移植到android,不,因为arm不使用帧指针,所以它仅显示堆栈的第一帧。

所以... 2是答案。

但是,我想知道是否有人可以解决问题:如何在SIGSEGV上使用_Unwind_Backtrace获取fullstacktrace

更新:

如果可以使用交叉编译器使用glic来编译代码,则可以使用3. backtrace! http://communities.mentor.com/community/cs/archives/arm-gnu/msg02514.html

update2 好文章

http://codingrelic.geekhold.com/2009/05/pre-mortem-backtracing.html