llvm bitcode 文件在 c# 中不能直接解析，必须通过 llvmsharp 调用原生 libllvm 实现；需严格匹配 abi 和架构，且所有修改必须经 ir 重建而非字节编辑。
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下载的 WindowsLLVM-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 注释。
