私はgdbのターゲット実行可能ファイルの外にいて、そのターゲットに対応するスタックさえ持っていません。私はx86アセンブリの専門家ではないので、とにかくシングルステップでアセンブリコードで何が起こっているのかを確認したいと思います。残念ながら、gdbはこの単純なアセンブリレベルのデバッグを行うことを拒否します。適切なブレークポイントで設定および停止できますが、シングルステップ以降を実行しようとすると、gdbは「現在の関数の境界が見つかりません」というエラーを報告し、EIPは変更されません。
追加の詳細:
マシンコードはgccasmステートメントによって生成され、objdump -dの出力から、それが実行されているカーネルメモリの場所にコピーしました。ローダーを使用してオブジェクトコードを再配置されたアドレスにロードする簡単な方法は気になりませんが、ロードはカーネルモジュールで実行する必要があることに注意してください。
別の代替策は、gdbに提供する偽のカーネルモジュールまたはデバッグ情報ファイルを作成して、この領域がプログラムコード内にあると信じ込ませることだと思います。gdbは、カーネル実行可能ファイル自体で正常に機能します。
(本当に知りたい人のために、実行時にVMware VM内のLinuxカーネルデータスペースにコードを挿入し、VMwareWorkstationの組み込みgdbスタブを介してカーネルをリモートデバッグするgdbからデバッグしています。カーネルを記述していないことに注意してください。悪用;私はプロトタイプを書いているセキュリティ大学院生です。)
(アセンブリ内の各命令にブレークポイントを設定できます。これは機能しますが、x86アセンブリ命令のサイズが異なり、再起動するたびにアセンブリの場所が変わるため、しばらくするとかなり面倒になります。)