c++ 符号执行klee c++如何用klee自动探索代码路径深度解析|Duuu笔记
KLEE 对 C++ 代码基本无效，因其仅支持无运行时依赖的纯 C 风格 LLVM bitcode，无法处理 std::string、异常、RTTI、虚函数表、构造/析构等引入的不可控符号与动态行为。
为什么 KLEE 对 C++ 代码基本无效
KLEE 本质只支持纯 C 风格的、无运行时依赖的 LLVM bitcode，而 C++ 的
std::string
、
std::vector
、异常、RTTI、虚函数表、构造/析构调用等，都会引入不可控的外部符号或动态行为。KLEE 在加载 bitcode 时遇到未定义的
_ZNSs4_Rep20_S_empty_rep_storageE
这类符号就直接报错退出，不是配置问题，是能力边界问题。
常见错误现象：
llvm-link: error: undefined reference to 'operator new(unsigned long)'
、
Unable to resolve symbol: _ZTVNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE
。
别尝试用
-stdlib=libc++
或静态链接
libstdc++.a
—— KLEE 不会执行构造函数，全局对象状态为空，
std::cout
等根本不可用
别指望
klee --link-llvm-lib
能补全 C++ 标准库 —— 它只接受裸函数定义，不处理 vtable 布局或 ABI 适配
哪怕你把所有 C++ 特性都删光，只留
class
声明和 POD 成员，只要用了
new
或隐式构造，bitcode 里就会出现 KLEE 无法求解的调用链
什么情况下能“凑合跑”C++ 片段
仅当代码被严格限制为 C 子集 + 极简封装：无 STL、无异常、无虚函数、无全局对象、所有类仅含 public POD 成员、所有函数用
extern "C"
导出、内存全部用
malloc
/
free
手动管理。
使用场景：验证某个算法逻辑（如解析器核心、密码学轮函数），且你愿意把原 C++ 类拆成 C 风格的
struct
+ 独立函数。
“
C++免费学习笔记（深入）
”；
编译命令必须用
clang++ -emit-llvm -c -g -O0 -std=c++11 -fno-exceptions -fno-rtti -D__STDC_LIMIT_MACROS
必须用
llvm-link
手动合并所有 .bc 文件，确保没有未解析符号 —— 可用
llvm-nm a.bc | grep ' U '
检查
入口函数必须是
int main(int, char**)
形式，且不能调用任何未提供实现的 C++ runtime 函数
klee_make_symbolic
在 C++ 里的危险用法
即使你绕过了链接问题，在 C++ 上调用
klee_make_symbolic
依然极易崩溃。因为 KLEE 不知道对象布局、对齐、padding，更不知道成员变量是否被构造过。
典型翻车点：对
std::array
整体做 symbolic，KLEE 会把它当一块裸内存处理，但实际访问
a[0]
时可能触发未定义行为；对
std::vector
的
data()
做 symbolic，底层指针本身是 concrete 的，但指向内容被标记 symbolic，KLEE 无法建模这种混合状态。
安全做法：只对 plain C-style
int*
、
char*
、
struct
指针做
klee_make_symbolic
绝对避免：对
this
指针、
std::unique_ptr
内部、
std::string::c_str()
返回值做 symbolic
若必须测试类逻辑，请先用
memcpy
把目标字段拷到独立
char buf[1024]
，再对
buf
调用
klee_make_symbolic
比硬刚 C++ 更靠谱的替代路径
真正想对 C++ 项目做路径探索，KLEE 不是工具选型问题，是范式错配。它适合验证已知结构的、小规模的、无状态的系统逻辑（比如协议解析器、加密算法），而不是通用 C++ 应用。
可考虑的务实方案：
用
clang++ -cc1 -x c++ -emit-llvm
生成 bitcode 后，用
opt -passes='lower-switch,lower-constant-intrinsics'
简化控制流，再喂给 KLEE —— 仅限极简函数
改用
LLVM-based fuzzing
（如 libFuzzer）+
AddressSanitizer
，它天然兼容 C++，能发现崩溃但不保证路径覆盖
对关键算法抽离为 C 接口（头文件只含
extern "C"
函数声明），在 KLEE 中单独验证，其余 C++ 逻辑走单元测试
最常被忽略的一点：KLEE 的路径爆炸不是算力问题，而是建模精度问题。C++ 的隐式行为越多（比如 copy elision、临时对象生命周期），KLEE 越难维持语义一致性 —— 这不是参数能调出来的。
