macOS 10.11下用libffi调用stat()返回错误值问题排查

我来帮你拆解这个问题——这本质上是macOS下符号别名和头文件宏替换搞出来的坑，咱们一步步说清楚：

核心原因：macOS的stat符号重定向 #

在macOS 10.5之后的64位系统中，为了兼容32位与64位inode格式，<sys/stat.h>里做了一个关键的宏替换：

#define stat stat$INODE64

也就是说，你在代码里写的stat()，编译器会自动替换成stat$INODE64()——这就是你的mystat函数能正常工作的原因：编译器帮你处理了这个替换，实际调用的是64位版本的stat。

而你直接用dlsym查找stat或者_stat时，拿到的是旧的32位stat版本，这个版本在64位环境下调用会因为参数不兼容、inode长度不匹配等问题返回错误。

关于nm输出的符号解释 #

你看到的nm输出里的两个符号其实是关联的：

• 0000000000001af7 T R8289209$_stat：这是stat的版本化符号别名，是macOS动态链接器用来管理符号版本的机制，它实际指向的就是stat$INODE64的实现。
• U _stat：这是未定义的符号占位符，编译时会被头文件的宏替换成_stat$INODE64，最终指向真正的64位实现。

而你用nm查看自己生成的.dylib得到U _stat$INODE64，就是宏替换后的结果——你的mystat里的stat()被替换成了stat$INODE64()，所以链接器会去找这个符号。

解决方案 #

要让libffi调用正常工作，你需要做这几件事：

1. 使用正确的符号名查找
   直接用dlsym查找"_stat$INODE64"（注意macOS下C函数符号会自动添加下划线前缀），而不是"stat"或"_stat"：

   void* stat_func = dlsym(libc_handle, "_stat$INODE64");
   

2. 匹配struct stat的正确布局
   确保你通过头文件解析得到的struct stat是64位版本的布局——32位和64位的struct stat字段长度（比如st_ino、st_size）差异很大，如果参数传递的结构体布局不匹配，调用后也会返回错误。

3. 避免硬编码符号名（可选优化）
   如果不想硬编码stat$INODE64，可以在代码里利用头文件的宏来动态获取符号名：

   #include <sys/stat.h>
   const char* stat_symbol = "_" #stat; // 预处理后会自动变成 "_stat$INODE64"
   

这样调整后，你的libffi调用应该就能和mystat一样正常工作了。

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