ARM64汇编调试：解决AEC崩溃与addr2line失效问题

1. 问题背景：当addr2line遇上顽固的AEC crash

作为一名长期深耕智能手机相机算法开发的工程师，最近在调试一个棘手的AEC（自动曝光控制）模块崩溃问题时，遇到了addr2line工具失效的情况。这个崩溃发生在高通相机服务进程中（/vendor/bin/hw/vendor.qti.camera.provider@2.7-service_64），具体是在SoloTMgr_1线程（tid: 3462）执行时触发的。

提示：AEC（Auto Exposure Control）是相机算法中负责自动调整曝光参数的核心模块，其稳定性直接影响成像质量。在复杂的计算过程中，整数溢出是常见的安全隐患。

崩溃堆栈显示问题出在CamX框架的AECBEStats17组件中，但当我们尝试用常规addr2line工具解析崩溃地址时，却只能得到函数名（AdjustROIParams），无法定位到具体代码行号。这种"半失明"状态给问题排查带来了极大困难，迫使我们不得不深入汇编层面寻找突破口。

2. 问题分析全流程实录

2.1 初探：常规addr2line的局限性

首先使用标准GNU addr2line工具解析崩溃地址：

bash复制aarch64-linux-android-addr2line -e camera.qcom.so 0x123456

输出结果仅有：

code复制CamX::AECBEStats17::AdjustROIParams
??:0

这种结果说明工具虽然能识别函数符号，但无法关联到源码行号。常见原因包括：

• 编译时未生成完整调试符号（-g选项）
• 符号表被strip处理过
• 地址对应编译器生成的隐式代码（如异常处理）

2.2 进阶：llvm-addr2line的突破

换用LLVM工具链中的增强版解析工具：

bash复制llvm-addr2line -e camera.qcom.so 0x123456

这次输出多个可能的源码位置：

code复制camxifeaecbestats17.cpp:196
camxifeaecbestats17.cpp:204
camxifeaecbestats17.cpp:211
camxifeaecbestats17.cpp:218
camxifeaecbestats17.cpp:270
camxifeaecbestats17.cpp:271

llvm-addr2line之所以能提供更丰富的信息，是因为它：

1. 支持DWARF调试格式的扩展特性
2. 能处理内联函数和模板实例化
3. 对优化后的代码有更好的回溯能力

2.3 深度：反汇编验证与地址偏移计算

通过objdump生成带源码对照的反汇编：

bash复制aarch64-linux-android-objdump -d -S --demangle camera.qcom.so > camera.qcom.so.txt

在反汇编文件中定位AdjustROIParams函数，发现关键特征：

• 存在6处条件分支跳转到溢出处理代码块
• 每个跳转前都有smulh（有符号乘法高位）指令
• 跳转目标地址与llvm-addr2line报告的源码行对应

典型汇编片段示例：

asm复制1a3b4:   9ac20c62    smulh   x2, x3, x2
1a3b8:   37000082    tbnz    w2, #0, 1a3c8 <AdjustROIParams+0x1d8>

这里smulh执行有符号乘法并保留高位，tbnz检查溢出标志位。

2.4 终局：源码与汇编的交叉验证

结合camxifeaecbestats17.cpp源码分析，确认llvm-addr2line提示的6个位置均存在敏感运算：

cpp复制// 示例位置1（行196）
int newWidth = roi->width * scalingFactor;  // 可能溢出
if (newWidth > MAX_WIDTH) {
    // 溢出处理
}

// 示例位置2（行271）
int area = width * height;  // 大尺寸相乘风险

通过UBsan（Undefined Behavior Sanitizer）进一步验证，确实捕获到有符号整数溢出：

code复制runtime error: signed integer overflow: 2147483647 * 2 cannot be represented in type 'int'

3. 汇编级调试技巧宝典

3.1 高阶工具链配置

1. LLVM工具集优势：

   • 安装NDK中的LLVM工具链

   bash复制sudo apt install android-ndk-llvm
   

   • llvm-objdump提供更丰富的反汇编注释

   bash复制llvm-objdump -d --source --sym=camera.qcom.so
   

2. 调试符号处理：

   • 编译时保留完整调试信息

   makefile复制LOCAL_CFLAGS += -g -fno-inline -fno-omit-frame-pointer
   

   • 使用split-debug-info保留符号

   makefile复制LOCAL_STRIP_MODULE := keep_symbols
   

3.2 关键地址解析流程

1. 计算相对偏移：

   python复制# 崩溃地址 - 模块加载基址 = 相对偏移
   offset = crash_address - module_base
   

2. 多工具交叉验证：

   bash复制# 使用nm查找函数范围
   nm -n camera.qcom.so | grep AdjustROIParams
   
   # 使用readelf查看节区信息
   readelf -S camera.qcom.so | grep .text
   

3.3 反汇编分析要点

1. ARM64关键指令：

   • 乘法溢出检查：smulh + tbnz组合
   • 除法保护：sdiv前的零检查
   • 数组边界：cmp + b.hi跳转

2. 模式识别技巧：

   • 错误处理通常有adrp加载字符串地址
   • 崩溃点附近常有bl调用日志函数
   • 编译器生成的保护代码往往有固定模式

4. 防御式编程实践建议

4.1 安全运算封装

cpp复制template<typename T>
bool SafeMultiply(T a, T b, T& result) {
    if (a > 0 && b > 0) {
        if (a > std::numeric_limits<T>::max() / b) return false;
    }
    // 其他边界情况处理...
    result = a * b;
    return true;
}

4.2 编译期防护

1. 启用UBsan检查：

   makefile复制LOCAL_CFLAGS += -fsanitize=undefined -fno-sanitize-recover
   

2. 关键模块加固：

   cpp复制__attribute__((no_sanitize("undefined"))) 
   void criticalSection() {
       // 明确标记已审核的安全代码
   }
   

4.3 调试信息优化

1. 保留关键符号：

   bash复制aarch64-linux-android-strip --keep-symbol=AdjustROIParams camera.qcom.so
   

2. 生成源码映射：

   bash复制llvm-dsymutil --oso-prepend-path=$(pwd) camera.qcom.so
   

5. 疑难排查速查表

在实际调试过程中，我发现ARM64架构下的整数溢出检查模式非常固定。通过编写自动化分析脚本，可以快速扫描反汇编文件中的危险模式：

python复制import re

def scan_overflow_checks(disasm_file):
    pattern = re.compile(r'smulh\s+x\d+,\s*x\d+,\s*x\d+\s*\n\s*tbnz\s+w\d+,')
    with open(disasm_file) as f:
        matches = pattern.findall(f.read())
        print(f"Found {len(matches)} potential overflow checks")

这种基于模式识别的分析方法，在大型二进制文件中定位问题效率极高。建议将常用检查模式整理成特征库，构建自动化安全审计流程