如何在运行时判断函数指针来自共享库还是主程序？

我在Ubuntu环境下用backtrace和backtrace_symbols捕获自定义异常时的栈跟踪，代码如下：

trace_size = backtrace(stack_traces, MAX_STACK_FRAMES);
messages = backtrace_symbols(stack_traces, trace_size);

从输出的栈帧里能提取出两类地址：

• 共享库地址：格式类似 /path/to/library.so(mangled_function_name+0x75) [0x7f02bcdfa849]，这里的0x7f02bcdfa849是共享库加载后的虚拟地址，不能直接传给addr2line
• 主程序地址：格式类似 /path/to/executable(mangled_function_name?+0x90) [0x403336]，这个地址可以直接用addr2line -e /path/to/executable 0x403336解析

之前我用字符串匹配.so来判断地址归属，但这种方法不严谨（比如主程序文件名可能包含.so，或者某些特殊共享库后缀不是.so）。下面是严谨的运行时判断方法：

严谨判断方案：利用dladdr和主程序路径对比 #

步骤1：获取当前主程序的绝对路径 #

通过/proc/self/exe这个符号链接可以获取主程序的真实路径，代码示例：

#include <unistd.h>
#include <cstring>

std::string get_executable_path() {
    char buf[PATH_MAX];
    ssize_t len = readlink("/proc/self/exe", buf, sizeof(buf)-1);
    if (len != -1) {
        buf[len] = '\0';
        return std::string(buf);
    }
    return "";
}

步骤2：对每个栈帧地址调用dladdr分析 #

dladdr会返回Dl_info结构体，包含该地址所属模块的路径（dli_fname）、模块加载基地址（dli_fbase）等信息。对比模块路径和主程序路径，就能判断地址归属：

#include <dlfcn.h>
#include <string>
#include <vector>

struct StackFrameInfo {
    std::string module_path;
    uintptr_t offset; // 相对于模块基地址的偏移
    bool is_executable; // 是否属于主程序
};

std::vector<StackFrameInfo> analyze_stack_frames(void** stack_traces, int trace_size) {
    std::vector<StackFrameInfo> result;
    std::string exec_path = get_executable_path();

    for (int i = 0; i < trace_size; ++i) {
        Dl_info info;
        if (dladdr(stack_traces[i], &info) != 0) {
            StackFrameInfo frame;
            frame.module_path = info.dli_fname;
            frame.is_executable = (frame.module_path == exec_path);
            
            // 统一计算相对于模块基地址的偏移
            frame.offset = reinterpret_cast<uintptr_t>(stack_traces[i]) - reinterpret_cast<uintptr_t>(info.dli_fbase);
            result.push_back(frame);
        }
    }
    return result;
}

步骤3：用计算后的偏移调用addr2line #

根据分析结果，对主程序和共享库分别处理：

• 主程序：addr2line -e /path/to/executable 0x<offset>
• 共享库：addr2line -e /path/to/library.so 0x<offset>

为什么字符串匹配不严谨 #

• 主程序文件名可能包含.so（比如特意命名为myapp.so的可执行文件），会导致误判
• 部分特殊共享库可能使用非.so后缀（比如某些系统模块），会导致漏判
• backtrace_symbols的输出格式可能因系统版本或编译选项略有差异，字符串匹配容易失效

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