2017-02-14 84 views
0

我正在使用VSCode + CodeLLDB + LLDB來調試JIT的語言(KL),但是我無法讓LLDB識別源文件。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

lldb只知道調試信息中寫入內容的源路徑。 DWARF中的規則(lldb使用的調試格式)是,如果包含文件只是由相對路徑或基本名稱給出,那麼它就是相對於編譯目錄而言的。看起來這就是你的情況。這聽起來像一個編譯器錯誤。在這一點上,lldb無法重建文件層次結構。

源地圖應該給你一個手動的方法來解決這個問題,並從它的聲音,你所描述的應該工作。但是也許在kl的DWARF輸出中有其他奇怪的東西讓人困惑。您需要用一些示例二進制文件來提交錯誤http://bugreporter.apple.com