Build integration¶
Two ways to run xollvm in a real build: a separate opt step on emitted IR, or in-compiler
via a clang extension point. Pick one — never both on the same translation unit (it would run twice).
Option A — opt round-trip¶
Explicit and toolchain-agnostic. Good for Make/CMake custom commands:
clang -S -emit-llvm -O0 app.c -o app.ll
opt -passes=obfuscation app.ll -S -o app.obf.ll -obf-seed=1 -obf-deterministic
clang app.obf.ll -O2 -o app
With the loadable plugin, add -load-pass-plugin=./Obfuscator.so to the opt line.
Option B — in-compiler¶
The obfuscator can run inside a normal clang compile via an extension point, gated by the default-off
-enable-obfuscation flag. Works with both clang and clang-cl, so it drops into existing build
systems that call clang per translation unit.
Only functions carrying an obf: annotation are transformed — without annotations the flag is a
no-op.
CMake¶
# Option B: obfuscate in-compiler for a target
target_compile_options(mysecrets PRIVATE
-mllvm -enable-obfuscation
-mllvm -obf-seed=1
-mllvm -obf-deterministic)
Use the xollvm-enabled clang (static extension) as CMAKE_C_COMPILER/CMAKE_CXX_COMPILER, or pass
-fpass-plugin=/path/Obfuscator.so for the loadable-plugin build.
Visual Studio / MSBuild¶
Set the project's compiler to xollvm's clang-cl (LLVM toolset), then add
/clang:-mllvm /clang:-enable-obfuscation (plus any seed flags) to C/C++ → Command Line →
Additional Options.
Don't obfuscate twice
If you use the in-compiler flag (-enable-obfuscation), do not also run a separate
opt -passes=obfuscation on the same IR — the passes would run twice.
Scope obfuscation to a few files
Because obfuscation is annotation-driven, you can safely enable -enable-obfuscation project-wide
— only annotated functions are touched. But for compile-time reasons, many projects put all
annotated functions in a small set of files and enable the flag only for those.