前言

在深入探索 LLVM 18 的世界中，我们意外地发现了一个有趣的问题——当我们尝试将 OLLVM 移植到 LLVM 18 时，原本顺畅无阻的 `fla` 程序突然遭遇了控制流平坦化的难题。这不仅是一个技术挑战，更是一次对编译器内部工作机制的深刻洞察。

移植过程中的意外

在将 OLLVM 迁移到 LLVM 18 的过程中，我们原本满怀期待地期待新环境能够完美兼容旧有的功能。然而，现实却给我们泼了一盆冷水——`fla` 程序在启用控制流平坦化（Control Flow Flattening）时，竟然抛出了一个难以理解的错误。

调试与分析

为了找出问题的根源，我们决定深入挖掘 LLVM 的内部工作原理。借助 CLion 的强大调试功能，我们逐步跟踪代码的执行流程，最终将目光锁定在了 `Flattening.cpp` 文件中的第 101 行。这里，一个看似简单的调用操作，却隐藏着一个致命的错误——访问权限冲突（0xC0000005）。

问题定位与解决

通过仔细分析，我们发现这个问题是由于在 `Flattening.cpp` 文件的第 65 行和第 97 行中，对同一个 `entryBB` 对象进行了两次相同的 `eraseFromParent()` 调用。这种重复操作导致了空指针异常，从而引发了整个程序的崩溃。

为了解决这个问题，我们将第 97 行的代码进行了修改，将原来的 `if(bEntryBB_isConditional)` 条件判断去掉，直接调用 `BB->getTerminator()->eraseFromParent()`。这样，我们就避免了重复删除同一终止指令，从而消除了空指针异常的风险。

重新编译与验证

修改完成后，我们再次使用 `ninja` 命令重新编译 LLVM，并生成了更新后的可执行程序。令人兴奋的是，这次 `fla.exe` 程序竟然能够正常运行了！我们激动地打开编译后的可执行程序，并使用 IDA 工具进行反汇编查看。结果令人震惊——经过控制流平坦化处理后的代码，竟然呈现出一种全新的、更加高效的执行效率。

结语

通过这次移植和修复的经历，我们不仅解决了实际问题，还对 LLVM 的内部机制有了更深入的了解。这为我们未来的开发工作提供了宝贵的经验和启示。如果你也对 LLVM 感兴趣，不妨一试这段神秘的移植之旅吧！

完整源码地址

想要深入了解这次移植和修复的完整过程吗？那就快来 GitHub 上搜索 "CYRUS-STUDI" 吧！那里有你需要的所有信息和资源。