我正在使用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是解决此问题的正确方法，但我对任何建议持开放态度（直到将每个源文件链接到我可以重定向到的平面文件夹中）。
答案 0 :(得分：0)
lldb只知道调试信息中写入的源路径。 DWARF中的规则（lldb使用的调试格式）是，如果包含文件仅由相对路径或基本名称给出，则它将被视为相对于编译目录。看起来这就是你的情况。这听起来像编译器错误。 lldb此时无法重建文件层次结构。
源地图应该为您提供一种手动方式来解决这个问题，从它的声音来看，您所描述的内容应该有效。但也许在kl的DWARF输出中有一些奇怪的东西让人感到困惑。您需要将一些示例二进制文件的错误提交到http://bugreporter.apple.com。