0

リリース モードで電話でデバッガーを実行すると、デバッガーに奇妙なエラーが発生します。xcode 4.3.3 で gdb または lldb を使用しているかどうかにかかわらず、コードの PC が実際にはその場所を指していなくても、コードはブレークポイントに到達します。

偽のコードの例:

if (true) {
    // set breakpoint-A here
} else {
    // set breakpoint-B here
}

// 別のブレークポイント C をここに設定します。

ブレークポイント B に着陸し、ブレークポイント A にジャンプします。

「リリース」モードにあり、最適化していることが原因ですか?

ありがとう！

4

2 に答える 2

3

はい、ここで 3 つのことが行われています。リリース モードでビルドすると、コンパイラは最適化されたコード生成を行います。コンパイラは、ソース行がプログラムにコンパイルされる順序を変更する可能性があり (コードの意味を変更しない限り)、異なるソース行間の命令が混在または再配置される可能性があり、最終的に行に問題が発生する可能性があります。コンパイラが発行するテーブル。

2 つのソース行があり、それぞれが 8 つのアセンブリ言語命令になると想像してください。コンパイラは、これらの 16 個の命令を (結果が変わらない限り) 再配置して、CPU を最も効率的に実行し続けることができます。しかし、この状況で、コンパイラーはどの命令が 1 行目に相当すると言うべきでしょうか? また、コンパイラが 2 行目と同等であると言うべき命令はどれですか?

最適化されたコード デバッグでは、ソース コード レベルでデバッグしている場合、プログラムをステップ実行している間に "現在実行中のソース行" が何度も跳ね返るという現実を受け入れなければなりません。スコープ内にあるように見える変数は、明らかでないときに現れたり消えたりします。コンパイラの方法はトリッキーで理解しにくいものです。何が起こっているのかを実際に追跡するには、目の前のアセンブリ言語コード (またはソース + アセンブリ表示) を使用してデバッグする必要があります。

最適化されたコードのソースレベルのデバッグを改善するために、コンパイラーとデバッガーが行うことができる改善がありますが、おそらく常に従うのは少し難しいでしょう。

于 2012-09-29T01:53:07.390 に答える
1

また、Xcode は、メソッド内の任意の return ステートメントから、そのメソッド内の最初の return ステートメントにジャンプする傾向があります。(Xcode 4.3.3 はまだそれを行います。4.5 についてはまだわかりません。)

最後に強調表示された「return」ステートメントは無視してください。

于 2012-10-03T02:04:00.003 に答える