LLDB无法识别源文件符号及栈帧编号不符的问题咨询

我的机器运行Ubuntu 22.04，通过$ sleep 10 & killall -SIGSEGV sleep生成sleep程序的核心转储文件，并分别通过debuginfod（GDB自动下载）和Ubuntu ddeb仓库获取了调试符号及coreutils源码。遇到以下现象：

• 使用GDB调试时，bt命令能显示所有栈帧的源文件路径；
• 使用LLDB调试时，即使添加调试符号，也无法显示sleep主函数对应的源文件路径；
• 当使用ddebs的调试符号时，LLDB能显示部分库函数的源文件，但仍无法显示sleep主函数的源文件；
• GDB与LLDB输出的栈帧编号不匹配，例如GDB中main函数是第4号栈帧，而LLDB中是第2号。

现咨询两个问题：

1. 为何LLDB无法显示部分栈帧（尤其是sleep主函数）的源文件名称，而GDB可以？
2. 为何GDB与LLDB的栈帧编号不匹配？

问题1：LLDB无法显示sleep主函数源文件路径的原因 #

这主要源于LLDB和GDB在调试符号处理、源码关联逻辑上的差异：

• debuginfod支持成熟度差异：Ubuntu 22.04配套的LLDB版本（多为14.x）对debuginfod的自动源码拉取支持不如GDB完善，针对coreutils这类系统工具的调试符号，LLDB无法像GDB那样自动完成符号与源码路径的关联映射。
• DWARF符号解析逻辑不同：对于Ubuntu ddeb仓库提供的调试符号，LLDB在解析DWARF格式的元数据时，可能遗漏了main函数对应的源码路径信息。GDB对ELF调试符号的DWARF解析逻辑更全面，能完整提取到主函数的源码路径关联。
• 源码路径映射机制差异：即使本地已下载coreutils源码，LLDB不会自动将调试符号中记录的编译时绝对路径，映射到本地的源码目录。而GDB会自动尝试路径匹配，LLDB则需要手动执行settings set target.source-map <编译时路径> <本地路径>命令来完成映射，尤其是当编译路径与本地路径不一致时。

问题2：GDB与LLDB栈帧编号不匹配的原因 #

两者的栈帧编号规则本身就存在根本性差异：

• GDB的编号规则：从当前执行的最顶层栈帧（比如触发SIGSEGV时的信号处理函数）开始，以0为起始编号，向下（调用链的底层方向）递增。因此main函数会被分配较大的编号（如示例中的4号）。
• LLDB的编号规则：从线程的最底层栈帧（通常是程序入口或main函数）开始，以0为起始编号，向上（调用链的上层方向）递增。所以main函数的编号会更小（如示例中的2号）。
• 简单总结：GDB是从当前执行点往main方向编号，LLDB是从main往当前执行点方向编号，这直接导致了相同栈帧在两个调试器中的编号完全不同。

内容的提问来源于stack exchange，提问作者Gordiig