问题标签 [addr2line]

我正在尝试使用addr2line存档文件libdpdk.a

我有一个回溯：

我尝试了以下命令：

预期的输出应该是回溯地址中函数的名称，0x46fd05或者0x46fd05取决于我传递的地址。目前没有与该地址关联的符号名称。

任何建议。

我已经编译了代码使用-rdynamic

我已将 gdb 附加到进程。我打印回溯，其中一个框架如下所示：

那是我的功能，但绝对不是我的文件。我预计这是由于内联。有没有一个命令可以告诉我这个内联是如何进行的？类似的东西addr2line -i？

为了比较，addr2line 的回溯略有不同，但很接近。

addr2line清楚的：

与-i：

我想以编程方式将回溯堆栈地址（例如从 backtrace_symbols/libunwind 获得）转换为 file:line:column。我在 OSX 上，但怀疑这会有所作为。

所有这些都为调用 fun1() 提供了错误的行号（第 11 行）：

• 阿托斯
• addr2line
• llvm-符号化器
• lldbimage lookup --address在 bt 中使用 lldb 的 pc 地址

lldbbt本身给出了正确的文件：行：列，（第 7 行），如下所示。

如何以编程方式获取正确的堆栈地址，以便在使用 atos/addr2line/llvm-symbolizer/image lookup --address 时，它会解析为正确的行号？lldbbt做得正确，所以必须有办法做到这一点。请注意，如果我使用backtrace_symbolsor （从调用后libunwind减去），我最终会得到与lldb bt 中所示相同的地址，该地址指向错误的行号 11info.dli_saddrdladdr0x0000000100000f74

注意：在 .lldbinit 中，如果我添加settings set frame-format frame start-addr:${line.start-addr}\n它将显示正确的地址（即解析为 0x0000000100000f6f 而不是 0x0000000100000f74，这将解析为正确的第 7 行）。但是，我如何以编程方式从 ac 程序生成 start-addr 而不调用产生调用lldb -p $pid（调用 lldb 有其他问题，例如与 llvm-symbolizer 相比的开销，实际上即使使用 也可以永远挂起-batch）。

test_D20191123T162239.c：

同样与addr2line

在我的嵌入式项目中，我amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.c以这种方式编译：

我已经ipconfigUSE_TCP设置为 1 inamazon-freertos/lib/FreeRTOS-Plus-TCP/include/FreeRTOSIPConfig.h

FreeRTOS_Sockets.c声明xBoundUDPSocketsList并xBoundTCPSocketsList

链接我的 elf 可执行文件后，运行以下命令：

这两个符号都存在于可执行文件中，但一个 ( xBoundTCPSocketsList) 似乎不属于任何 .c 源。两者都出现在地图文件中：

即使 addr2line 失败：

甚至FreeRTOS_Sockets.lst没有告诉我更多信息：

可执行文件中还有许多其他符号，但它们似乎与任何 .c 源文件无关。

为什么会有这种行为？两个符号xBoundTCPSocketsList和之间有什么变化xBoundUDPSocketsList？编译时是我弄错了还是省略了一些调试参数？如何获取 nm 或其他方式来获取声明符号的 .c 源？

编辑：

我认为问题不在于链接

事实上，即使我分析，我也会得到相同的 arm-none-eabi-nm 输出./build/DSP/amazon-freertos/lib/FreeRTOS-Plus-TCP/FreeRTOS_Sockets.o：

有时用户会在我的应用程序中看到崩溃。他们正在运行签名版本，但我能够从他们的 logcat 中获取 tombstone 崩溃数据。尝试使用在线示例来运行 addr2line 但我需要符号来执行此操作。

1. 我在哪里可以找到符号？我的应用程序中没有任何个人 NDK 代码。但我可能使用的一些库使用了它们。这个应用程序是建立在 Jenkins 上的，我在任何地方都看不到符号

2. 'base.apk' 是否表明这是我的 java/kotlin 代码中的错误？

Tombstone（实际包名替换为 <pkg_name>：

08-10 13:53:59.693 26885 27004 F libc：致命信号 11 (SIGSEGV)，代码 1，tid 27004 (Thread-22) 中的故障地址 0xa0，pid 26885 (<pkg_name>.stg) 08-10 13:53 ：59.938 27700 27700 F 调试：*** *** *** *** *** *** *** *** *** *** *** *** *** * ** *** 08-10 13:53:59.938 27700 27700 F 调试：构建指纹：'Zebra/TC57/TC57:8.1.0/01-23-18.00-OG-U00-STD/12:user/release-键' 08-10 13:53:59.938 27700 27700 F 调试：修订：'0' 08-10 13:53:59.938 27700 27700 F 调试：ABI：'arm64' 08-10 13:53:59.938 27700 27700 F 调试: pid: 26885, tid: 27004, name: Thread-22 >>> <pkg_name> <<< 08-10 13:53:59.938 27700 27700 F DEBUG : 信号 11 (SIGSEGV), 代码 1 (SEGV_MAPERR), 故障地址0xa0 08-10 13:53:59.938 27700 27700 F 调试：原因：空指针取消引用 08-10 13:53:59。938 27700 27700 F DEBUG : x0 0000000000000000 x1 0000000000000003 x2 0000000000000000 x3 00000079d7368918 08-10 13:53:59.938 27700 27700 F DEBUG : x4 00000079d7368918 x5 0000000000000000 x6 0000000000000000 x7 0000000000000000 08-10 13:53:59.938 27700 27700 F DEBUG : x8 0000000000000000 x9 0000000000000000 x10 0000000000000199 x11 0000000000000030 08-10 13:53:59.938 27700 27700 F DEBUG : x12 0000000000000000 x13 ffff000000000000 x14 00000000000000ec x15 00000079d90b2810 08-10 13:53:59.938 27700 27700 F DEBUG : x16 00000079d91bcad0 x17 0000007a766e0680 x18 00000079d90b3010 x19 00000079d1317400 08- 10 13:53:59.938 27700 27700 F DEBUG : x20 00000079d1317408 x21 00000079d7368608 x22 00000079d59f4f38 x23 0000000000000013 08-10 13:53:59.938 27700 27700 F DEBUG :x24 00000079d59f4fa0 x25 0000000000000000 x26 0001f2fbd8469ce3 x27 00000079d7c9eb60 08-10 13:53:59.938 27700 27700 F DEBUG : x28 0000000000000001 x29 00000079d59f5450 x30 00000079d8ddf518 08-10 13:53:59.938 27700 27700 F DEBUG : sp 00000079d59f4d10 pc 00000079d8e1411c pstate 0000000020000000 08-10 13 - ：53:59.947 27700 27700 F 调试：08-10 13:53:59.947 27700 27700 F 调试：回溯：08-10 13:53:59.948 27700 27700 F 调试：#00 pc 0000/0000002771 ixNeuAJ0yHvNhkAJXdw0Tg==/base.apk (offset 0x440000) 08-10 13:53:59.948 27700 27700 F DEBUG : #01 pc 0000000000242514 /data/app/<pkg_name>-ixNeuAJ0yHvNhkAJXdw0Tg==/base.apk (offset 0x440000) 08- 10 13:53:59.948 27700 27700 F 调试：#02 pc 00000000002425cc /data/app/<pkg_name>-ixNeuAJ0yHvNhkAJXdw0Tg==/base。apk（偏移量 0x440000）08-10 13:53:59.948 27700 27700 F 调试：#03 pc 0000000000244fe0 /data/app/<pkg_name>-ixNeuAJ0yHvNhkAJXdw0Tg==/base.apk（偏移量 0x4400003：59）：0.8 27700 27700 F DEBUG : #04 pc 0000000000245478 /data/app/<pkg_name>-ixNeuAJ0yHvNhkAJXdw0Tg==/base.apk (offset 0x440000) 08-10 13:53:59.948 27700 27700 F DEBUG : #05 pc 0000000000245490 /data/app /<pkg_name>-ixNeuAJ0yHvNhkAJXdw0Tg==/base.apk (offset 0x440000) 08-10 13:53:59.948 27700 27700 F 调试: #06 pc 00000000002503e8 /data/app/<pkg_name>-ixNeuAJ0yH=dbaseNapX/偏移0x440000）08-10 13：53：59.948 27700 27700 F调试：＃07 PC 000000000025057C/DATA/App/App/<pkg_name> -Ixneuaj0yhvnhkajxdw0tg=/base.apk（offse） F 调试：#08 pc 00000000002454bc /data/app/<pkg_name>-ixNeuAJ0yHvNhkAJXdw0Tg==/base.apk（偏移量 0x440000）08-10 13:53:59.948 27700 27700 F 调试：#09 pc 000000/00002 ixNeuAJ0yHvNhkAJXdw0Tg==/base.apk (offset 0x440000) 08-10 13:53:59.948 27700 27700 F DEBUG : #10 pc 000000000024a120 /data/app/<pkg_name>-ixNeuAJ0yHvNhkAJXdw0Tg==/base.apk (offset 0x440000) 08- 10 13:53:59.948 27700 27700 F 调试：#11 pc 0000000000202cc0 /data/app/<pkg_name>-ixNeuAJ0yHvNhkAJXdw0Tg==/base.apk（偏移量 0x440000）08-10 13:570:59.9740 DE 2 pc 00000000001e823c /data/app/<pkg_name>-ixNeuAJ0yHvNhkAJXdw0Tg==/base.apk (offset 0x440000) 08-10 13:53:59.948 27700 27700 F DEBUG : #13 pc 0000000000492f1c /data/app/<pkg_name>-ixNeuAJ0yHvNhkAJXdw0Tg= =/基地。apk (offset 0x440000) 08-10 13:53:59.948 27700 27700 F DEBUG : #14 pc 0000000000067f8c /system/lib64/libc.so (__pthread_start(void*)+36) 08-10 13:53:59.900 27700 27调试：#15 pc 000000000001f2b4 /system/lib64/libc.so (__start_thread+68)

我的程序不时崩溃，并在系统日志中显示以下消息。

这是否可以以某种方式对其进行修改，因此将有一条关于函数/行在哪里崩溃的可读消息而不是地址？

我可以访问程序源，并且可以通过 addr2line 查找函数。然而，我感兴趣的是我想让它解析指向函数的指针，所以它会在 syslog 中看到。请分享您对如何实现此功能的想法

UPD：我看到可以通过注册信号处理程序并执行 backtrace() 函数来完成。这是一种无需修改程序即可做到这一点的方法吗？或者是否可以进行一些通用修改，所以每个程序都会在崩溃时执行回溯？

使用 backtrace 和 backtrace_symbols，我可以获得一个感兴趣的错位函数名称（我们将其称为属于 libfsw.so 的 funcA_mangledName。

我的目标是获取定义它的源文件和行号。我可以对未在库文件中定义的函数执行此操作，如下所示。stacktrace 保存回溯。文件名 = S_main_executable 在一般情况下。

但是，当函数是库的一部分时，这不起作用，即文件名 = libfsw.so。

向后工作我可以在 linux 终端上执行此操作：

得到：000000000020cbea T funcA_mangledName

然后当我进入linux终端时：

我得到了正确的源文件和行号。

从一开始到正确的文件偏移量，我缺少什么？

我在我的 android 应用程序中的一个库中遇到问题。应用程序崩溃了，并且写了墓碑。现在应用程序正在使用一堆 c++ 库和一些第三方库。我遇到的问题是在墓碑中我看到这样的东西：

现在我已经设法获取了这个 apk 并将其提取出来，我普遍怀疑是哪个库通过日志中的这一行导致了这个问题：

我在日志中搜索了这个 tid，并从一些库中找到了一堆日志，具有相同的 tid。比我使用 addr2line 并在这个库中找到了一些方法，但我不是 100% 确定这是有效的方法。我想知道有什么办法可以连接这个从墓碑偏移的地址

到特定的库？在这种情况下，最佳做法是什么？谢谢

为什么我在 clang 编译的最近文件中看到这么多 0 行号地址？

就像下面 llvm-dwarfdump 的结果：

什么编译器标志导致它？