トレースを使用しているときに、ブレークポイントを設定するためにそれらを検索しようとしたときに、いくつかの関数がソースにリストされていないことがわかりました。これらの関数は、ソースをアセンブリ形式で表示した場合にのみ表示されるようです。
先輩に話を聞いたところ、関数が1回だけ呼び出されると、Traceによって最適化され、インラインとして表示されるため、アセンブリで確認できるとのことでした。
私の質問は次のとおりです。
- この最適化はローターバッハを通じてどのように行われますか?
- これは有利ですか?
いくつかのことがあります:
ステートメントに関して、ブレークポイントを設定するためにそれらを見つけようとしているときにソースにリストされていない関数がいくつかあることがわかりました。 "ビルドで使用されたさまざまな関数で構成されるマッピングファイル/マップファイル、それらの場所を確認してくださいメモリなどで関数が見つからない場合は、最適化を調べてください[それだけが問題になる可能性があります]。
正しく指摘されているように、最適化はLauterbachによって行われるのではなく、コンパイラによって行われます。通常、さまざまな最適化レベルがあります[ARMではO0-O2があります]。ここで、O0は可能な限り最高の最適化ですが、これは顧客へのリリースがある場合にのみ使用する必要があります。それ以外の場合は、デバッグに最適化レベルO2を使用する必要があります。
関数がコンパイラによって最適化されていると思われる場合は、揮発性にしてみてください。
これに[直接]関係しないかもしれないが役立つかもしれない他のポイントは、何かをデバッグしたいときにそのページがまだRAMにない場合、何度も「メモリのどの領域にファイルがあるか」を知ることです。そのページがRAMに取り込まれるまで、ブレークポイントを設定することはできません[基本的に、システムに存在する場合はオンデマンドページングのようなもの]
お役に立てれば。
-hjsblogger
最適化は、Lauterbachではなくコンパイラによって行われます。コンパイラはアセンブリ言語の出力を最適化しようとします。デフォルト設定では、通常、一度だけ呼び出される関数がインライン化されます。
テスト目的でこれらの最適化をオーバーライドするには、コンパイラフラグ--no_inlineを使用できます。
一度だけ呼び出される関数のインライン化は、コンパイラーによって実行される場合があります。
利点は、関数呼び出しのオーバーヘッド(ランタイム、コードスペース、スタックスペース)を節約し、複数の関数として優れたモジュール方式でコードを記述できることです。
欠点は、デバッグ中に呼び出し元と機能が混同されるため、デバッグが難しくなることです。
トレースツールの動作について、質問はかなり不明確です。
ソースコードで見つからない関数が呼び出されている場合、次の2つの理由から、インライン関数が原因である可能性はほとんどありません。
インライン化された関数呼び出しは、アセンブリコードではサブルーチン呼び出しとして表示されません-関数を実装するためのコードは、関数呼び出しが行われるポイントでインライン化されます(これがインライン化です)。
コンパイラが関数呼び出しをインライン化する場合、関数名(アセンブリ出力に表示されている場合)は引き続きソースコードの一部であり、コンパイラがコードをインライン化する場所です。
ただし、コンパイラは、CPUが直接サポートしていない算術演算(整数除算や浮動小数点演算など)などを実装するために、生成されたコードに内部ヘルパー関数への不思議な関数呼び出しを挿入することがあります。
「ミステリー機能」の名前は何ですか?