2017-02-14 16 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だけでエラーアウトする:)口実を探しているほとんどかのように思えます。

注 - ブレークポイントを設定してローカルを表示できますが、その場所でソースコードを表示できないようです。

誰でもこの問題に対処する方法はありますか? - LLDBを使ってソースファイルを探す/修正する - CodeLLDBを修正してLLDBとVSCodeの間のパスを変更する - VSCodeに与えられたパスを無視して、名前に一致するファイル。

私は、LLDBがこれを修正する適切な場所だと思っていますが、私はリダイレクトできるフラットフォルダに各ソースファイルをリンクする時点まで、何か提案しています。

答えて

0

lldbは、デバッグ情報に記述されているものからのソースパスのみを知っています。 DWARF(デバッグ形式lldbが使用する)の規則は、インクルードファイルが相対パスまたはベース名によって指定された場合、コンパイルディレクトリに対して相対的なものになります。あなたの場合に起こっているように見えます。それはコンパイラのバグのように聞こえます。 lldbは、この時点でファイル階層を再構築することはできません。

ソースマップでは、これを修正する手動の方法が必要です。また、その音から、動作するはずのものを記述する必要があります。しかし、おそらく、それが混乱しているklのDWARF出力には他に奇妙なことがあります。バイナリの例をhttp://bugreporter.apple.comにしてバグを報告する必要があります。