ORC JIT不能直接运行动态C++字符串代码，仅接受已构建的Module对象；需显式创建Module、设ExternalLinkage、归属JITDylib、注册外部符号（如printf）、调用addIRModule，再通过lookup获取JITSymbol、getAddress()并reinterpret_cast为函数指针后调用。
ORC JIT 不能直接运行动态生成的 C++ 字符串代码，它只接受已构建好的 Module 对象，并将其编译为可执行机器码；函数调用必须通过符号查找 + 强制类型转换完成。
如何把 IR 模块喂给 ORC JIT 并触发编译
ORC 不会自动监听或扫描代码——你得显式构造 Module、填入函数、再调用 addIRModule。常见错误是传入空 Module 或未设置函数 linkage：
-
Function::Create必须指定Function::ExternalLinkage，否则lookup找不到符号 - 模块必须归属某个
JITDylib（如es.createBareJITDylib("main")），不能裸奔 - 若模块含外部调用（如
printf），需提前用DynamicLibrarySearchGenerator::GetForCurrentProcess注册当前进程符号，否则lookup返回nullptr - 调用
addIRModule后不立即编译：ORC 默认 lazy 编译，首次lookup才触发编译（除非你套了EagerlyCompileLayer）
怎么拿到函数指针并安全调用
lookup 返回的是 JITSymbol，不是地址；必须调用 getAddress() 并强转为具体函数类型，否则运行时崩溃：
// 假设 add(int, int) 已加入 JIT
auto sym = mainJD.lookup("add");
if (!sym) { /* 处理失败 */ }
int (*fp)(int, int) = reinterpret_cast<int (*)(int, int)>(sym->getAddress());
int result = fp(3, 4); // 正确调用
- 类型必须完全匹配：参数个数、顺序、
const、返回值，C++ 成员函数指针不支持 -
getAddress()可能抛std::system_error（如符号未解析成功），务必检查sym是否有效 - 不要缓存
getAddress()结果跨多次addIRModule调用——旧模块卸载后地址失效
为什么 ExecutionSession 和 JITDylib 生命周期不能乱管
ORC 的内存和符号生命周期由 ExecutionSession 统一管理；误删 JITDylib 或提前析构 ExecutionSession 会导致野指针或 double-free：
- 模块添加后，其内存由
SectionMemoryManager分配，释放靠JITDylib::removeModule或JITDylib析构 -
ExecutionSession析构时会阻塞等待所有异步编译完成，若你在多线程中提前 delete 它，程序大概率 crash - 多个
JITDylib间默认隔离符号；想让 A 看到 B 的函数，得调用A.addDependence(B) - 调试时常见陷阱：在
main()结束前没显式removeModule，导致进程退出时 ORC 强制清理引发 SIGSEGV
最易被忽略的一点：ORC 的 symbol resolution 是延迟且依赖上下文的。lookup("foo") 成功不代表 foo 已编译完成，只是表示它“可编译”；真正生成机器码发生在第一次调用该函数指针时——如果函数体里又引用了另一个未注册的符号，此时才暴露出链接问题，而不是 addIRModule 阶段。
