カーネルのデバッグにQEMUを使用しようとしています。最初に試しましたが、仮想ファイルシステムがないため失敗しました。答えこの投稿仮想ファイルシステムを使用することをお勧めします。ただし、カーネルデバッグ用の仮想FSを作成する方法とそれをqemuに渡す方法については説明しません。助けてください?
答え1
使用する展開に応じて、次のファイルシステムイメージを生成する方法はいくつかあります。この記事あなたを大変な道に導く「最初からLinux」システム。
一般的に言えば、あなた誰でも次を使用して QEMU イメージをqemu-img
生成します。QEMUの使用インストールメディアを使用して画像を準備します(このページではDebian GNU / Linuxプロセスについて説明します。)または他の人が準備した画像を使用してください。
QEMU Wikibookのこのセクション必要なすべての情報が含まれています。
編集する:
リンクされた質問に対するGilesの答えからわかるように、テストには完全なルートファイルシステムは必要ありません。画像の使用initrd
(例:以下に示すArch Linuxのinitrd)
答え2
Ubuntu 16.10ホストでテストされたQEMU + GDBステップバイステップ手順
最初から素早く始めるために、次の場所で最小限の完全自動化されたQEMU + Buildrootの例を作成しました。https://github.com/cirosantilli/linux-kernel-module-cheat主なステップは次のとおりです。
まず、ルートファイルシステムを入手してくださいrootfs.cpio.gz
。必要に応じて、次の点を考慮してください。
- 最小
init
実行可能イメージ:1つのプログラム、1つのプログラムのみを実行するようにLinuxディストリビューションをカスタマイズする - Busyboxインタラクティブシステム:最小のLinux実装は何ですか? UnixとLinuxのスタック交換
その後、Linuxカーネルで:
git checkout v4.9
make mrproper
make x86_64_defconfig
cat <<EOF >.config-fragment
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_GDB_SCRIPTS=y
EOF
./scripts/kconfig/merge_config.sh .config .config-fragment
make -j"$(nproc)"
qemu-system-x86_64 -kernel arch/x86/boot/bzImage \
-initrd rootfs.cpio.gz -S -s
他の端末で次からデバッグを開始するとしますstart_kernel
。
gdb \
-ex "add-auto-load-safe-path $(pwd)" \
-ex "file vmlinux" \
-ex 'set arch i386:x86-64:intel' \
-ex 'target remote localhost:1234' \
-ex 'break start_kernel' \
-ex 'continue' \
-ex 'disconnect' \
-ex 'set arch i386:x86-64' \
-ex 'target remote localhost:1234'
もう終わりました!
カーネルモジュールについては、以下を参照してください。QEMUを使用してLinuxカーネルモジュールをデバッグする方法は? |スタックオーバーフロー
hbreak
Ubuntu 14.04ではGDB 7.7.1が必要で、break
ソフトウェアブレークポイントは無視されます。 16.10ではこれ以上そうではありません。また見なさい:https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/901944
混乱disconnect
と次に起こるのはエラーを解決することです。
Remote 'g' packet reply is too long: 000000000000000017d11000008ef4810120008000000000fdfb8b07000000000d352828000000004040010000000000903fe081ffffffff883fe081ffffffff00000000000e0000ffffffffffe0ffffffffffff07ffffffffffffffff9fffff17d11000008ef4810000000000800000fffffffff8ffffffffff0000ffffffff2ddbf481ffffffff4600000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000
関連トピック:
- https://sourceware.org/bugzilla/show_bug.cgi?id=13984GDBのバグの可能性があります
- gdb - リモート 'g' パケット応答が長すぎます。
- http://wiki.osdev.org/QEMU_and_GDB_in_long_modeosdev.orgはいつものように、これらの質問のための素晴らしいソースです。
- https://lists.nongnu.org/archive/html/qemu-discuss/2014-10/msg00069.html
また見なさい:
- https://github.com/torvalds/linux/blob/v4.9/Documentation/dev-tools/gdb-kernel-debugging.rst公式Linuxカーネル「ドキュメント」
- GDBとQEMUを使用してLinuxカーネルをデバッグする方法は? |スタックオーバーフロー
既知の制限事項:
- Linuxカーネルではサポートされていません(パッチなしでコンパイルすることはできません)
-O0
。Linuxカーネルを最適化解除し、-O0でコンパイルする方法は? |スタックオーバーフロー - 修正後も、GDB 7.11はいくつかのタイプのタブ補完機能であなたを驚かせます
max-completions
。大容量バイナリファイルのタブ完了ハングスタックオーバーフロー今回のパッチで扱わないコーナーケースがあるかもしれません。したがって、ulimit -Sv 500000
デバッグする前にこれを行うことをお勧めします。特に、file<tab>
次のパラメータのタブを完了するときfilename
:sys_execve
Linuxカーネルのsys_execve()システムコールは絶対パスと相対パスの両方を受け取ることができますか? |スタックオーバーフロー