C语言Mock open()系统调用时gcov代码覆盖率生成失败问题

核心原因：gcov运行时依赖原生open()写入数据 #

gcov的覆盖率统计逻辑是：编译时给代码插桩，程序运行时在内存里累计覆盖数据，程序退出阶段，gcov的运行时库会自动调用open()打开.gcda文件，再用write()把统计数据写进去。

当你Mockopen()时，相当于把进程里的open()符号替换成了自己实现的版本。gcov的运行时代码属于当前进程的一部分，它调用的open()就是你Mock后的版本——如果你的Mock实现没处理.gcda文件的打开请求，自然会导致gcov打不开文件，抛出profiling:/xxx/my-coverage.gcda:Cannot open错误。

与其他Mock函数的关键区别 #

• 依赖优先级不同：open()是gcov写入覆盖率数据的入口级依赖，没有它，后续所有写操作都无法启动；而pread()这类函数要么不在gcov的核心工作流程里，要么不是必要依赖，Mock它们不会影响gcov生成数据。
• 调用触发时机不同：gcov在程序退出时主动调用open()，不管你的测试逻辑有没有用到这个函数；而其他被Mock的函数（比如业务逻辑里的pread()）只有在测试用例触发对应代码路径时才会被调用，只要Mock逻辑不干扰gcov的运行，就不会出问题。
• 系统调用的基础属性：open()是最基础的文件系统入口调用，几乎所有涉及文件操作的组件都会依赖它；而有些系统调用属于更上层的操作，gcov的运行时可能根本不会用到，所以Mock后无影响。

可行的解决方法 #

• 给Mock的open()加白名单：在你的Mock实现里判断，如果打开的文件路径包含.gcda后缀，就调用原生的open()系统调用（可以通过dlsym(RTLD_NEXT, "open")获取原生函数地址）。
• 针对性Mock而非全局替换：用Mock框架的局部打桩功能，只拦截测试业务逻辑中需要Mock的open()调用，放行gcov相关的请求（比如Google Test里用EXPECT_CALL指定匹配条件，只处理特定路径的open()）。
• 测试后恢复原生实现：如果是全局Mockopen()，在测试用例执行完毕后，及时恢复原生的open()函数，确保gcov在程序退出时能正常调用。

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