使用するディストリビューションに応じて、ファイル システム イメージを作成するさまざまな方法があります。この記事では、"Linux from Scratch" への骨の折れる方法を順を追って説明します。 システム。
全般 、あなたはどちらか qemu-img
を使用して QEMU イメージを作成します 、一部のディストリビューションのインストール メディアを取得し、QEMU を使用 イメージを準備するためのインストール メディア (このページでは Debian GNU/Linux のプロセスについて説明します) または 他の人が用意した画像を使用してください。
QEMU Wikibook のこのセクションには、必要なすべての情報が含まれています。
編集: リンクされた質問に対するGillesの回答が示唆するように、テストに本格的なルートファイルシステムは必要ありません。 initrd
を使用するだけです 画像 (例えば Arch Linux の initrd のようなもの)
Ubuntu 16.10 ホストでテストされた QEMU + GDB の段階的な手順
ゼロからすばやく開始するために、完全に自動化された最小限の QEMU + Buildroot の例を https://github.com/cirosantilli/linux-kernel-module-cheat で作成しました。主な手順は以下で説明されています。
最初にルートファイルシステム rootfs.cpio.gz
を取得します .必要な場合は、以下を検討してください:
- 最小限の
init
-実行可能イメージのみ:1 つのプログラムだけを実行するカスタム Linux ディストリビューション。 Unix &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 カーネル モジュールをデバッグする方法を参照してください。 | |スタック オーバーフロー
Ubuntu 14.04、GDB 7.7.1、hbreak
の場合 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=13984 は GDB のバグの可能性があります
- gdb - リモート 'g' パケット応答が長すぎます |スタック オーバーフロー
- http://wiki.osdev.org/QEMU_and_GDB_in_long_mode osdev.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() システム コールは、絶対パスと相対パスの両方を受け取ることができますか? | |スタック オーバーフロー