私はstraceとltraceについて知っていますが、それはプロセスがそれぞれ実行しているシステムコールとライブラリコールを教えてくれるだけです。プロセスが実行している命令を正確に知りたいのですが。アセンブリ、または可能であればCとアセンブリの間のある種の中間点。バイナリがデバッグシンボルでコンパイルされていないと仮定すると、最初のオプションに傾く可能性が高くなります。
ユースケース:プロセスがハングしているように見え、straceまたはltraceからの出力がありません。プロセスが「何か」を行っているかどうかを判別します。これは停止性問題の解決に類似していると思うので、これを判断するのは難しいかもしれません。ただし、有用なデータを収集できる場合があります。
2番目のユースケース:好奇心。アセンブリ命令のリスト全体をテキストリストにダンプするのは興味深いことです。
私の推測では、gdbを使用してこれを行うことができますが、これは私が作成したプログラムのデバッグに関するものではなく、実行中のプロセスの状態をチェックするためのgdbの使用に関するものであるためです。
OSはCentOS6です。
これは、gdb
で実行できます。コマンドni
およびsi
は、一度に1つの命令を実行します。コマンドn
は、「next」のほとんどの値に対して、コードの次の行を実行します。 n
(および対応するs
)の場合、デバッグシンボルが実行可能ファイルに表示されるようにコンパイルする必要があります。
このstackoverflowの回答 これを多かれ少なかれ視覚的に行うためのいくつかの方法を示します。
gdb
コマンド:display/i $pc
は、実行前の命令を表示します。 display $pc
n
またはs
が実行する前のコード行を表示します。
プロセスIDでps -l
を実行し、S
(「状態」)列を確認します。状態がR
の場合、プロセスはコードを実行しています。プロセスが状態R
のままで、strace
がシステムコールの実行を示していない場合、プロセスは非常に長く、場合によっては無限の計算にトラップされます。プロセスが状態D
であり、その状態が続く場合、システムコールでブロックされます。プロセス状態の詳細については、 このプロセスSTATは何を示しますか? 、 「割り込み可能なスリープ」状態は何を示しますか? および What if'kill- 9 'は機能しませんか? 。
プロセスが長い計算を実行している場合は、Gdb(または別のデバッガー)を使用して、プロセスの動作を確認できます。実行可能ファイルにデバッグ情報がない場合(通常、そのためにプログラムをコンパイルしなかった場合)、デバッガーはマシン命令のみを表示できます。実行可能ファイルにデバッグ情報が含まれている場合は、スタックトレースなどで関数の名前を確認できます。 Gdbをプロセスにアタッチするには、gdb /path/to/executable 1234
を実行します。ここで、1234
はプロセスIDです。コマンドs
を使用すると、一度に1つずつ命令を実行できます。あなたがプログラマーであり、プログラムが何をすることになっているのかをある程度理解していない限り、このシナリオでGdbから有用な情報を得る可能性はほとんどありません。