LLDB：为扁平化文件夹结构指定源搜索文件夹

Question

我正在使用 VSCode + CodeLLDB + LLDB 来调试 JIT 语言 (KL)，但是我无法让 LLDB 识别源文件。

这是对LLDB equivalent of gdb "directory" command for specifying source search path? 的重复问题，但已接受的答案对我不起作用。

LLDB 似乎认为每个源单元都编译到本地目录 - 所以如果我执行

kl /MyWork/someFile.kl

并且这个文件包括 /any/other/path/external.kl，LLDB 会认为该文件位于 /MyWork/external.kl

到目前为止，我（主要）正在使用

解决这个问题

settings set target.source-map /MyWork/ /any/other/path/

但这似乎只适用于单个文件夹。如果我尝试过：

settings set target.source-map /MyWork/ /any/other/path/
settings set target.source-map /MyWork/ /I/use/many/dependencies/

然后 LLDB 似乎无法在任一文件夹中找到 -any- 文件。有趣的是，当我尝试这个 LLDB 时，错误的消息是准确的

can't find external.kl in /I/use/many/dependencies/
can't find dependencies.kl in /any/other/path/

哪些是准确的消息，但似乎 LLDB 只是在寻找出错的借口:)。

注意 - 我可以设置断点并查看本地变量，但我似乎无法在那个位置查看源代码。

Anywho - 对如何处理这个问题有什么建议吗？有 3 种可能的工作方式： - 修改/使用 LLDB 查找源文件 - 修改 CodeLLDB 以修改 LLDB + VSCode 之间的路径 - 以某种方式说服 VSCode 忽略为其提供的路径，并在其自己的文件夹中搜索与该名称匹配的任何文件。

我怀疑 LLDB 是解决此问题的正确位置，但我愿意接受任何建议（直到将每个源文件链接到我可以重定向到的平面文件夹）。

Answer 1

lldb 只知道调试信息中写入的源路径。 DWARF（lldb 使用的调试格式）中的规则是，如果包含文件仅由相对路径或基本名称给出，则它被认为是相对于编译目录的。看起来这就是你的情况。这听起来像一个编译器错误。此时 lldb 将无法重建文件层次结构。

源地图应该为您提供一种手动解决此问题的方法，并且从它的声音来看，您所描述的应该可以工作。但也许在 kl 的 DWARF 输出中还有一些奇怪的东西让它感到困惑。您需要使用一些示例二进制文件向http://bugreporter.apple.com 提交错误。