不完全なスタック展開

スタック展開の定義については、「呼び出しスタックとプログラムの実行」を参照してください。

スタック展開は、次のようないくつかの場合に失敗します。

• ユーザーコードによってスタックが破壊されている場合。スタックが破壊された原因によっては、プログラムまたはデータ収集コードでコアダンプする場合があります。

• ユーザーコードが、関数呼び出しの標準の ABI 規則に従っていない場合。特に、SPARC プラットフォームで、保存命令が実行される前に復帰レジスタ %o7 が変えられる場合。

  どんなプラットフォームでも、手書きのアセンブラコードには規則違反がある場合があります。

• リーフ PC の関数内の位置が、呼び出し先のフレームがスタックからポップされた後、また関数が復帰する前である場合。

• 呼び出しスタックに約 250 を超えるフレームが含まれている場合、この呼び出しスタックを完全に展開するだけの領域がコレクタにはありません。この場合、呼び出しスタックの _start から特定の時点までの関数の PC は実験ファイルに記録されません。疑似関数 <Truncated-stack> は、記録された一番上のフレームを集計するため、<Total> から呼び出されたものとして示されます。

• x86 プラットフォームで、最適化された関数のフレームをコレクタが展開できなかった場合。

中間ファイル

-E または -P コンパイラオプションを使用して中間ファイルを生成すると、アナライザは元のソースファイルではなく、この中間ファイルを注釈付きソースコードとして使用します。-E を使用して生成された #line 指令は、ソース行へのメトリックスの割り当てで問題が発生する原因となることがあります。

関数が生成されるようにコンパイルされたソースファイルへの参照用の行番号を持たない関数からの命令が存在する場合、次の行が注釈付きのソースに現れます。

function_name -- <instructions without line numbers>

行番号は、次の条件下では欠落することがあります。

• -g オプションを指定しないでコンパイルした場合。

• コンパイルのあとにデバッグ情報がストリップされた場合、またはその情報を含む実行可能ファイルかオブジェクトファイルが移動、削除、変更された場合。

• 関数が、オリジナルのソースファイルではなく、#include ファイルから生成されたコードを含む場合。

• 高レベルの最適化で、コードが異なるファイルの関数からインライン化された場合。

• ソースファイルに、ほかのファイルを参照する #line 指令がある場合。たとえば、-E オプションを使用してコンパイルし、その結果の .i ファイルをコンパイルすることによって起こります。-P フラグを使用してコンパイルした際にも起こりえます。

• 行番号情報を読み取るオブジェクトファイルが見つからない場合。

• 使用したコンパイラが、不完全な行番号テーブルを生成する場合。