BDWGC项目中空对象文件导致的可执行栈问题分析

问题背景

在BDWGC（Boehm-Demers-Weiser垃圾收集器）项目中，Makefile.direct文件将atomic_ops_sysdeps.o列入了NODIST_OBJS变量。这个变量被用于测试程序和共享库（如liblinuxgc.so等）的构建规则中。然而，atomic_ops_sysdeps.o在大多数情况下是一个空对象文件，只有在使用非GCC编译器构建Sparc架构时才会包含实际内容。

问题现象

当GNU链接器（ld）处理这个空对象文件时，由于缺乏明确的栈属性指示，它会默认假设共享库需要可执行栈。较新版本的GNU ld会对此发出警告：

/usr/bin/ld: warning: atomic_ops_sysdeps.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

通过scanelf工具可以确认生成的共享库确实被标记为需要可执行栈：

% scanelf -e ./libgc.so   
 TYPE   STK/REL/PTL FILE 
ET_DYN RWX R-- RW- ./libgc.so 

技术分析

这个问题源于2014年的一个提交（gc-7.6.x），当时将atomic_ops_sysdeps.o添加到了构建系统中。在大多数构建场景下，这个文件是空的，但却导致了不必要的可执行栈标记。

在CMake构建系统中也存在类似情况，但处理方式更为合理：只有当使用SunPro编译器（SunCC）在SunOS（Solaris）上构建时，才会包含atomic_ops_sysdeps.S源文件。不过，CMake需要显式启用ASM语言支持才能正确处理.S文件。

解决方案

项目维护者采取了以下修复措施：

1. 从非SunOS共享库目标中移除了atomic_ops_sysdeps.o，避免了空对象文件的引入
2. 在CMake构建系统中显式启用了ASM语言支持，确保.S文件能被正确处理
3. 在libatomic_ops子项目中同步了相关修复

安全影响

可执行栈在现代系统中被认为是一个潜在的安全风险，因为它可能被利用来执行恶意代码。虽然在这个特定情况下风险较低（因为栈实际上并不需要执行权限），但消除这种不必要的标记仍然是一个良好的实践。

结论

这个问题展示了构建系统中细微的设计决策可能带来的意外后果。通过仔细分析构建依赖关系并针对特定平台进行条件化处理，项目维护者成功解决了这个问题，同时保持了跨平台兼容性。这也提醒开发者在处理平台特定代码时需要特别注意其对构建产物的影响。