uftrace项目中的i386架构库函数追踪问题分析与修复

问题背景

uftrace是一个功能强大的函数追踪工具，能够帮助开发者分析程序的运行时行为。在最新发布的v0.15候选版本中，开发团队发现了一个严重问题：当在i386架构(32位x86)上使用库函数追踪功能时，程序会出现段错误(Segmentation Fault)。

问题现象

当用户在i386架构下编译测试程序并尝试使用uftrace进行追踪时，会出现以下错误：

$ uftrace t-abc.32
WARN: child terminated by signal: 11: Segmentation fault
WARN: cannot open record data: /tmp/uftrace-live-bno4Hw: No data available

然而，当禁用库函数追踪功能时，程序能够正常工作：

$ uftrace --no-libcall t-abc.32
# DURATION     TID     FUNCTION
            [ 10225] | main() {
            [ 10225] |   a() {
            [ 10225] |     b() {
   0.432 us [ 10225] |       c();
   1.369 us [ 10225] |     } /* b */
   1.875 us [ 10225] |   } /* a */
            [ 10225] |   /* linux:task-exit */

问题分析

通过GDB调试，开发团队获取了程序崩溃时的调用栈信息。崩溃发生在处理PLT(Procedure Linkage Table)和GOT(Global Offset Table)的过程中，具体是在find_got函数内部执行memcpy操作时。

深入分析发现，问题的根本原因在于uftrace在处理32位和64位ELF文件时存在差异。在i386架构下，重定位条目(relocation entries)的大小与x86_64架构不同，但代码中错误地使用了64位的结构体大小进行计算。

具体来说，在find_got函数中，代码使用sizeof(Elf64_Rela)或sizeof(Elf64_Rel)来计算跳转次数，而没有考虑32位架构下这些结构体的大小差异。这导致计算出的内存地址不正确，最终引发段错误。

解决方案

开发团队提出了以下修复方案：

1. 不再硬编码使用64位结构体大小，而是从ELF文件中动态获取重定位条目的大小
2. 使用DT_RELENT或DT_RELAENT动态节区中的值来确定正确的条目大小
3. 使用更通用的指针类型来处理重定位条目，避免特定架构的假设

关键修复代码如下：

/* 获取重定位条目大小 */
case DT_RELENT:
case DT_RELAENT:
    jmprel_ent_size = iter->dyn.d_un.d_val;
    break;

/* 使用动态获取的条目大小进行遍历 */
for (size_t i = 0; i < jmprel_nr; i += jmprel_ent_size) {
    bool found = false;
    typeof(sec_iter.rel) *rel = (void *)jmprel_addr + i;
    /* ... */
}

修复效果

应用修复后，i386架构下的库函数追踪功能恢复正常：

$ uftrace t-abc.32 
# DURATION     TID     FUNCTION
   0.608 us [ 39766] | __monstartup();
   0.329 us [ 39766] | __cxa_atexit();
            [ 39766] | main() {
            [ 39766] |   a() {
            [ 39766] |     b() {
            [ 39766] |       c() {
   0.261 us [ 39766] |         getpid();
   0.928 us [ 39766] |       } /* c */
   1.293 us [ 39766] |     } /* b */
   1.628 us [ 39766] |   } /* a */
            [ 39766] |   /* linux:task-exit */

技术启示

这个问题的解决过程提供了几个重要的技术启示：

1. 跨平台兼容性：在开发支持多架构的工具时，必须特别注意不同架构下数据结构的差异。32位和64位架构不仅仅是指针大小的区别，许多系统数据结构的大小和布局也可能不同。

2. ELF格式处理：处理ELF文件时，应该尽可能使用动态信息而非硬编码值。ELF格式本身就提供了足够的信息来描述其内部结构，如重定位条目大小等。

3. 防御性编程：在访问内存前，应该进行充分的验证，确保计算出的地址是有效的。特别是在处理来自外部文件的数据时，这一点尤为重要。

4. 测试覆盖：跨平台项目需要确保在所有支持的架构上都有充分的测试覆盖。这个问题在64位架构上不会出现，但在32位架构上就会暴露出来。

通过这次问题的分析和解决，uftrace项目在跨平台兼容性方面又向前迈进了一步，为后续支持更多架构积累了宝贵经验。