AArch64设备SIGSEGV场景下backtrace_symbols()返回空值问题

我在信号处理函数中尝试获取调用栈回溯，从手册页抄的简单代码在armv7平台能正常运行，但到AArch64平台就出问题了。两个平台都用了-rdynamic -funwind-tables -no-pie编译选项（也试过加-g）。backtrace()返回非零值，但遍历strings打印或写入文件时会触发段错误；换成backtrace_symbols_fd()虽然不崩，但输出文件始终是空的——这些操作在armv7上都正常。两台设备的glibc版本一致，我不想用uClibc或libunwind这类替代方案，该从哪些方向排查？

相关代码：

int nptrs;
    void *buffer[BT_BUF_SIZE];
    char **strings;
    nptrs = backtrace(buffer, BT_BUF_SIZE);
    printf("backtrace() returned %d addresses\n", nptrs);

    strings = backtrace_symbols(buffer, nptrs);
    if (strings == NULL) {
        perror("backtrace_symbols");
        exit(EXIT_FAILURE);
    }

排查方向 #

• 信号处理函数的异步安全限制：AArch64对异步信号安全的要求更严格，backtrace_symbols()和backtrace_symbols_fd()依赖的内存分配、字符串处理函数（比如malloc、sprintf）可能不是异步安全的，在信号上下文里调用会导致竞态或内存损坏。可以尝试在信号处理里只收集backtrace()的地址，然后切换到主线程中去解析符号。
• AArch64的栈布局与unwind信息差异：用readelf -u命令对比armv7和AArch64二进制文件的unwind表，检查是否存在unwind信息缺失的情况。AArch64的栈帧结构、寄存器保存规则和armv7不同，若unwind信息不完整，会导致backtrace收集的地址后续解析失败。
• 二进制的PIE状态确认：即使添加了-no-pie编译选项，也要用file命令确认最终生成的二进制是否真的是非PIE格式。AArch64下部分编译器可能默认存在隐藏的PIE相关处理，导致符号解析时地址计算出错。
• 信号栈空间限制：AArch64的默认信号栈大小可能与armv7不同，backtrace_symbols()需要分配内存，若信号栈空间不足，可能导致内存分配失败或后续访问越界。可以尝试通过sigaltstack手动设置更大的信号栈后再测试。
• glibc架构相关实现差异：虽然两台设备的glibc版本号一致，但不同架构的glibc实现细节可能存在差异。可以查看glibc中backtrace系列函数的AArch64源码，确认是否存在信号上下文下的特殊处理逻辑，或是已知的架构相关bug。
• 符号解析的地址转换问题：AArch64的地址空间布局（如TTBR0/TTBR1的使用）可能导致backtrace收集的虚拟地址无法正确映射到符号表中的地址。用objdump -d查看二进制的符号地址，对比backtrace返回的地址，检查是否需要额外的偏移计算才能正确解析符号。

内容的提问来源于stack exchange，提问作者Adlmc