ピークスタックポインタ値とそのPC位置を測定する

Question

異なるバイナリを分析するために、実際のスタックメモリ使用量（予約されたスタックページだけでなく、実際に使用されたメモリ）を測定する必要があります。私は、これはlsとしても、短期実行中のプログラムのために以外ls、に適用されたとき、実際に進行し表示されませんが、それが立ち往生しています「仕事」に表示されますgdbの

watch $sp 
commands 
silent 
if $sp < $spnow 
    set $spnow=$sp 
    set $pcnow=$pc 
    print $spnow 
    print $pcnow 
    end 
c 

で次のことをしようとしていました/usr/lib/libc.so.6の "strcoll_l（）"のような関数で使用します。おそらく、この方法論では遅すぎるでしょう。

私もvalgrind massifツールを調べました。スタックの使用状況をプロファイルできますが、残念なことにピーク使用量がプログラムのどの部分で発生したかを報告できないようです。

異なるバイナリの分析のために

Answer 1

、私はピーク実際のスタックメモリの使用量を測定する必要が

あなたのGDBのアプローチだけでシングルスレッドプログラムの

• 作品
• もあります実行が遅くなります（watch $spコマンドはGDBにプログラムのシングルステップ実行を強制します）。

あなただけのページ単位でスタックの使用量を気に（と私はあなたがすべきと思いますか？ - それはプログラムがスタックの1024または2000バイトを使用したかどうか本当に問題ない）場合には、はるかに高速アプローチがにありますプログラムが正常に実行されている間にそのプログラムをループで実行し、プログラムが正常に実行されている間に（たとえば、デフォルトの8MBで開始し、次に4,2,1,512Kなどを試してから、正確な値）。 /bin/lsについては

：

bash -c 'x=4096; while /bin/ls > /dev/null; do 
     echo $x; x=$(($x/2)); ulimit -s $x || break; done' 
4096 
2048 
1024 
512 
256 
128 
64 
32 
bash: line 1: 109951 Segmentation fault  (core dumped) /bin/ls > /dev/null 

あなたはその後、coreダンプを見て、$PCを見つけることができます。

コンパイラの最適化がどのようなマイクロ変更でスタックを使用するのかを把握したいので、正確な制限が必要です（.dataと.textのサイズとともにバイト範囲でも）。

私はそれを試みるのは馬鹿だと信じています。

私の経験では、スタックの使用はコンパイラのインライン化の決定の影響を最も受けます。これらは、正確なコンパイラのバージョンとチューニング、実行時の情報の存在（プロファイルに基づく最適化用）、最適化されるプログラムの正確なソースによって最も影響を受けます。

インライン化の決定をYes/Noに変更すると、再帰プログラムのKB単位でスタック使用量を増やすことができ、上記の要因のいずれかを少し変更するとその決定が変更される可能性があります。