LLVM Bitcode 文件在 C# 里不能直接解析
LLVM 的
.bc文件是二进制格式，基于自定义的 bitstream 编码，不是标准序列化协议，也没有官方 C# 绑定。你用
System.IO.File.ReadAllBytes能读出来，但直接解析会卡在 magic header 之后——那堆变长整数、abbrev table、block nesting 完全没文档可查，更别说语义层（如函数签名、指令类型）了。
常见错误现象：
InvalidDataException或解包出一堆零值；有人试图用
BinaryReader手动跳字段，结果在 block 类型 0x12 处永远对不上 offset。 别自己写 bitstream 解析器：LLVM 的编码规则（如 Elias Delta、abbrev reuse、block scope 嵌套）在 C++ 实现里散落在
BitstreamReader.cpp数千行中，C# 重实现几乎必然漏 case 不要依赖“通用二进制解析库”：bitcode 不是 Protocol Buffers 或 Cap’n Proto，没有 schema，所有结构由运行时 context 动态决定 真实使用场景只有一种：需要读取 bitcode 元信息（如 target triple、function names）或做轻量 rewrite（比如 patch 某个 global init），而非完整 IR 遍历
用 LLVMsharp + libLLVM 是目前最稳的方案
LLVMSharp是 .NET 封装，背后调用系统已安装的
libLLVM（Linux/macOS）或
LLVM.dll（Windows）。它不解析 bitcode，而是把
LLVMModuleRef当黑盒加载，再通过 C API 暴露的稳定接口读取内容——这才是 LLVM 官方支持的用法。
关键点：
LLVMSharp本身不带 LLVM 运行时，必须额外部署对应版本的 native 库（例如 LLVM 17.0.6），且 ABI 必须严格匹配。 安装方式：
dotnet add package LLVMSharp+ 手动把
libLLVM.so/
LLVM.dll放到
runtimes/<os>/native/</os>下，否则
DllNotFoundException加载 bitcode：
LLVM.ParseBitcodeInContext2(context, dataPtr, dataSize, out string error)，注意
dataPtr必须是 pinned 内存（用
GCHandle.Alloc(bytes, GCHandleType.Pinned)） 获取函数名示例：
foreach (var fn in module.Functions) { Console.WriteLine(LLVM.GetValueName(fn)); }，这里 fn是
LLVMValueRef，name 是 runtime 提取的，不是从 bitcode 字节里硬抠的
跨平台部署时 libLLVM 版本和 CPU 架构必须一致
LLVM 的 bitcode 格式虽向后兼容，但
libLLVM的 C API 二进制接口（ABI）不是。你在 macOS ARM64 上编译的
libLLVM.dylib，放到 Linux x86_64 上直接
LoadLibrary失败；LLVM 16 的
LLVMGetNamedFunction函数签名在 17 里可能已改，导致
AccessViolationException。
典型报错：
Unable to load DLL 'LLVM': The specified module could not be found（其实是架构不匹配），或者
Attempted to read or write protected memory（ABI 错位）。 检查目标机是否真有对应 lib：Linux 用
ldd yourapp.dll | grep llvm，Windows 用
dumpbin /dependents LLVM.dll不要混用预编译包：
llvm.org下载的 Windows
LLVM-17.0.6-win64.exe自带
LLVM.dll，但它的导出符号是
LLVMGetGlobalParent@8这种 stdcall，而
LLVMSharp默认按 cdecl 调用，需手动 patch binding 或换用
llvm-project自编译的版本 建议固定 LLVM 版本：在 CI 中用
apt install llvm-17-dev（Ubuntu）或
brew install llvm@17（macOS），然后链接对应
libLLVM-17.so/
libLLVM-17.dylib
想修改 bitcode？只能通过 LLVM IR API 间接生成新 bitcode
bitcode 是只读序列化输出，LLVM 不提供“编辑某条指令 opcode”的 API。所有修改都得走“load → build new IR → verify → emit bitcode”流程。比如想把某个 call 指令替换成 noop，实际要：
LLVMDeleteFunction原函数 →
LLVMAddFunction新函数 → 用
LLVMBuild*()系列重建 BB →
LLVMWriteBitcodeToFD输出。
性能影响明显：一次修改触发整个 module 重验证，大文件（>10MB）可能卡住几秒；而且生成的 bitcode 和原始文件的 block layout 不同，diff 工具看不出逻辑变化，但字节完全不一样。
别试图 patch 原始.bc文件：bitstream 的 block size、abbrev id、CRC 都是动态计算的，改一个字节会导致后续全部解析失败 如果只要删函数，用
LLVMRemoveFunctionFromParent+
LLVMDisposeFunction，比重建快；但新增指令必须走 builder 输出新 bitcode 时注意：
LLVMWriteBitcodeToFile(module, "out.bc")生成的是未压缩版，体积比 clang -c -emit-llvm 产出的大 2–3 倍，如需压缩得调
LLVMWriteBitcodeToFD+ 自己接 zlib
bitcode 的“可操作性”本质是借 LLVM C API 的壳，底层全是 C++ 对象生命周期和内存管理在扛。哪天你发现
LLVMDisposeModule后程序崩了，大概率是某个
LLVMValueRef还被 pin 在 managed heap 里——这种细节，文档里不会写，但跑不通就只能翻
LLVM-C.h注释。
