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