使用-m32编译的C++程序为何调用getdents64，是否与-fopenmp有关？

你之前的认知核心误区，是把编译目标的ELF格式属性和运行时系统调用集合的约束混为一谈，具体偏差点：

• -m32参数的作用范围仅在代码生成阶段：它会让编译器生成32位指令集的用户态代码、输出符合32位x86 ELF格式的二进制文件，全程不会对程序最终链接调用的系统调用逻辑做任何强制约束。
• 不存在“32位ELF程序只能触发32位语义系统调用”的规则：在x86_64体系的现代内核上，32位用户态程序是完全可以触发带64位语义的系统调用的。
• 现代glibc的32位兼容库，已经默认放弃了传统老32位系统调用的封装：比如你遇到的getdents64调用，根本不是编译时生成的指令逻辑自带的，而是glibc的目录读取函数封装，在32位环境下现在默认会发起getdents64，替代早就被内核标记为兼容层的老版getdents系统调用——哪怕你的程序本身一行相关的系统调用代码都没写，只要调用了glibc的opendir/readdir函数，就会走这个封装。

OpenMP不是异常的直接根因，但其配套的运行时库会间接触发这个调用路径：

• 编译时加-fopenmp会自动链接对应架构的libgomp运行时库，这个库在初始化阶段，通常会遍历系统的/sys//proc路径枚举可用计算核心、做线程亲和性绑定，这个过程本身就会调用glibc的目录读取接口，间接触发getdents64。
• 哪怕你完全删掉所有OpenMP相关的代码、去掉-fopenmp参数，只要程序存在其他会触发目录读取的逻辑——比如基准测试的文件遍历、glibc加载动态库时的路径搜索、配置文件解析的目录扫描——照样会触发这个系统调用，和OpenMP没有本质关联。

• 先做变量隔离验证：临时去掉-fopenmp参数重新编译同一份代码，如果运行时还是会触发getdents64，就可以完全排除OpenMP的影响。
• 若要适配仅支持传统32位系统调用的模拟器，不要使用现代x86_64系统自带的32位兼容glibc做编译，换用纯32位x86环境下编译的旧版glibc（2.30及更早版本），这类版本的glibc默认仍封装老版getdents系统调用，不会强制走getdents64路径。
• 可通过链接时的函数包装能力，用-Wl,--wrap=getdents64把程序对该系统调用的调用重定向到自实现的、走传统32位系统调用的兼容逻辑，绕开glibc的默认封装。
• 从长期适配角度看，不如给模拟器补充getdents64的支持——目前主流32位glibc早就将这个调用作为目录读取的默认实现，再找完全不触发该调用的编译环境成本会越来越高。

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