クラッシュ レポートを取得すると、クラッシュ レポートがシンボル化されていても、実際の行番号が表示されるのではなく、コードの問題のある部分が次のように表示されることがあります。
-[ViewController myMethod:] + 47
これをデバッグするには、視覚的に検査したり、ブレークポイントを設定したりできるように、これがコードのどの行を表しているかを知る必要があります。
上記のように、LLDB を使用してメソッドのアドレスとオフセットを取得する良い方法は何ですか?
注: この質問は、クラッシュ レポートの読み方と重複するものではありません。クラッシュレポートの読み方を知っています。LLDB を使用して対応する行を取得する方法を具体的に尋ねています。他の回答には、その方法が示されていません。それらは非常に冗長で、クラッシュ レポートの処理と一般的なデバッグに関するあらゆる種類のものに入りますが、LLDB の特定の手順が何であるかは示していません。このバグを複製しないでください。
あなたのステップ ( image lookup+ p/x addr + offset) は、あなたが見つけたように、生のアドレスを提供します。しかし、元のクラッシュ レポートには、メソッド + オフセットの前にアドレスが含まれていた可能性がありますtarget modules load。クラッシュ レポートの最後には、ロード アドレスや UUID など、プログラムに存在するバイナリ イメージのリストが表示されます。
しかし、もっと重要なことは、アドレスは適切ですが、実際に求めているのはソースの場所です。その場合、メソッドの正しいアドレスを決定したら (または を介して一致するアドレスにスライドさせますtarget modules load)、次を使用できます。source list
(lldb) so l -a `addr + offset`
ここでは、インライン式の評価を行うバックティック表記を使用しています。アドレスを取るほとんどのコマンドには便利なショートカットがあります: スペースを省略すると、バッククォートなしで式を書くことができます:
(lldb) so l -a addr+offset
アドレスでも使えimage lookupます。デバッグ情報がある場合、この時点での変数の現在の場所がわかります。なぜこれが役立つのですか？ほとんどのクラッシュ レポートにはクラッシュ時のレジスタ コンテキストが含まれているため、現在レジスタにあるすべての変数が提供されます (-vすべてのレジスタ ロケーション情報を取得するために必要です)。
(lldb) im loo -v -a addr+offset
最後に、Objective-C メソッド名を扱っているため、これは機能しませんが、単純な C 関数名を使用すると、関数名をポインター型 (関数ポインターにオフセットを追加することは正当な C ではありません)。例えば
(lldb) so l -a (char*)main+10