llvm生成代码时崩溃的根本原因常是调试元数据在优化或后端处理中被破坏、丢弃或脱节；需编译时加-g -fno-omit-frame-pointer并避免opt/llc静默抹除!dbg，确保llvm-symbolizer可准确定位源码行。
LLVM生成代码时崩溃，根本原因往往不是调试信息丢了，而是调试信息在优化或后端处理中被破坏、丢弃或与实际指令脱节。只要编译阶段保留了完整且合法的 !dbg 元数据，并在关键环节避开“静默抹除”行为，崩溃时仍能用 gdb 或 llvm-symbolizer 定位到源码行。
Clang 编译时必须加 -g 且禁用局部变量优化
很多崩溃发生在后端（如 llc 或 lld 阶段），但问题根源其实在前端：Clang 没生成可信赖的调试元数据。
-
-g是底线，但仅加-g不够 —— 若同时启用-O2或更高优化级，Clang 默认会省略局部变量描述（DILocalVariable）、折叠内联范围，导致gdb看不到变量值或跳过断点 - 必须显式加上
-fno-omit-frame-pointer：否则 x86_64 下帧指针被优化掉，backtrace无法正确展开调用栈 - 对 Clang 17+，推荐用
-gdwarf-5替代默认-gdwarf-4，它支持更细粒度的变量生命周期描述，尤其在寄存器重用频繁的优化代码中更稳定 - 若你用
clang -O1 -g编译后发现gdb里变量显示为<optimized out></optimized>，立刻换-O0 -g -fno-omit-frame-pointer复现——这不是后端问题，是前端已放弃生成该变量的调试描述
避免 opt / llc 破坏 !dbg 元数据链
LLVM IR 经过 opt 优化或 llc 代码生成时，若未正确传播调试元数据，就会导致最终二进制中 !dbg 指向失效指令、空节点，甚至整个 DISubprogram 被丢弃。
-
opt默认不保留调试信息；执行任何 pass 前，务必加-debugify（LLVM 15+）或-strip-debug的反向操作（旧版需手动插桩） - 不要用
opt -O2 input.bc -o output.bc直接优化 —— 这会剥离所有!dbg。正确写法是：opt -O2 -debugify -verify input.bc -o output.bc -
llc生成汇编时，必须加-g参数（即使输入 IR 已含!dbg），否则它会忽略所有调试元数据，输出的.s文件里没有.loc或.file指令 - 若你看到
llc报 warning：Ignoring debug info for variable 'x' — no valid location，说明某条优化 pass 把产生该变量的指令删了，但没调用substituteDebugValuesForInst更新引用——这时应回退到未优化 IR，或加-debug-pass=Structure查哪 pass 干的
崩溃发生时，用 llvm-symbolizer 替代 gdb 加载符号
当 gdb 加载 core 文件后显示全是 ??，不代表调试信息没了，很可能是符号路径或版本不匹配。直接用 llvm-symbolizer 解析原始地址更可靠。
- 确保你有未 strip 的目标文件（比如
foo.o或foo.bc），而不是最终strip过的可执行文件 - 用
llvm-symbolizer -obj=foo.o -functions=linkage -inlining=true输入崩溃地址（如0x4012a3），它会返回精确的file:line和内联上下文 - 若地址来自
core，先用addr2line -e foo -fCi对比结果；两者不一致，说明gdb加载的是错误的符号文件（比如用了 stripped 版本或不同构建时间的 binary） - 注意：
llvm-symbolizer不依赖 DWARF 的 .debug_* section 是否被 objcopy 剥离 —— 只要 IR 或目标文件里还嵌着!dbg或.debug_line，它就能工作
真正容易被忽略的，是调试信息的“时效性”：哪怕你每步都加了 -g，只要中间某个 opt 或 llc 步骤漏掉了 -g 或 -debugify，整条链就断了。不要假设“前面有 !dbg，后面自然就有”，LLVM 后端对调试信息是“按需加载、显式传播”的，少一个 flag，就少一截现场。
