高保真构建工具封装与blight框架

作者：William Woodruff | 2020年11月25日

摘要

我们开源了blight框架，用于无痛封装和插桩C/C++构建工具。该框架已应用于我们的研究项目，并包含一系列实用操作组件，可立即用于构建过程的测量和插桩需求。

为什么需要封装构建工具？

工程师通常将构建工具视为黑盒（如gcc、clang++等），输入源文件后直接获取输出结果。我们进一步用高级构建系统（Make、Ninja）或构建系统生成器（CMake）封装这些工具，以规避C/C++编译的常规问题。

但这种传统方式在以下场景存在局限：

缓存优化

常规构建系统的缓存机制无法跨项目共享中间文件。ccache和sccache等工具通过封装构建工具实现了全局缓存，当相同输入已存在输出时直接复用。

静态分析

clang-tidy等静态分析工具需要准确知晓编译参数（如语言标准版本）。编译数据库（JSON格式记录所有构建命令）可解决此问题，CMake和Bear工具支持生成此类数据库。

性能分析

C/C++构建易出现性能问题：

昂贵标准头文件引入导致编译膨胀
复杂模板/递归宏降低编译速度
前向声明等优化模式失效

通过封装工具可注入-ftime-report等性能分析标志，无需修改构建系统。

构建安全保障

虽然编译器提供ASLR、控制流完整性等防护措施，但在复杂构建链中容易错误配置。封装工具可确保安全标志始终正确注入。

构建工具的复杂性挑战

构建工具封装需要深入理解工具命令行语法：

GCC有数千个选项，含四种不同传参语法
Clang虽兼容GCC但新增特有选项（如-Oz优化）
MSVC的cl.exe前端存在根本性差异

常见认知误区：

“编译器每次只处理一个输入” → 实际上支持多文件编译
“编译器每次只产生一个输出” → 隐式生成多个.o文件
“cc只编译C，c++只编译C++” → 都基于同一前端，可通过-x指定语言
“编译器每次只处理单一语言” → 实际支持混合编译C/C++源文件

blight架构设计

blight采用工具替换方案，通过环境变量覆盖默认工具链：

1

CC=blight-cc make -e

核心组件：

Tool基类：包含参数向量、工作目录等基础属性
Action机制：支持before_run/after_run两种钩子
Mixin模式：通过组合实现功能扩展，如：
- ResponseFileMixin处理@file参数文件语法
- 使用Python Enum严格建模标志行为（如-std=STANDARD）

实践案例

内置Action示例

IgnoreWerror：移除编译器中的-Werror标志
InjectFlags：注入可配置参数集

自定义Action开发

只需继承blight.action.Action并实现钩子方法：

1
2
3
4
5
6


class SayHello(blight.action.Action):
    def before_run(self, tool):
        print(f"About to run {tool}!")
    
    def after_run(self, tool):
        print(f"Just ran {tool}!")

配置管理

通过环境变量实现灵活配置：

1

BLIGHT_ACTION_INJECTFLAGS='CFLAGS=-O3 LDFLAGS=-Wl,--strip-all'

创新应用场景

实时构建统计看板（WebSocket传输数据）
改进WLLVM/GLLVM工具，精准跟踪内联汇编等边缘情况
优化标志矩阵测试框架

blight为构建工具封装提供了标准化基础设施，使开发者能专注于核心功能开发而非CLI解析。我们已将其用于内部项目，欢迎社区参与贡献！

使用blight实现高保真构建工具封装与插桩技术

本文介绍了Trail of Bits开源的blight框架，该框架能够无缝封装C/C++构建工具并实现编译过程插桩，支持性能分析、静态检查、缓存优化等高级构建场景，解决了传统构建工具封装中的各种技术难题。