はじめに

普段やっているデバッグの方法というか方針というか，そういうものを書いてみたいと思います．
といっても，結論は地道に根気よくバグを探す，といった感じなのですが...

なにでデバッグするか?

基本的にはBitVisor のprintf() 関数でログを出してのデバッグです．

ログはネットワーク越しに出力します．

ただ，あまりにも起動初期の段階(ネットワークドライバの初期化前とか)にpanic すると，ネットワーク越しからはログが見れません．
なので，そういうときはVGA出力でみます．
(ちなみに，vmm.driver.pci の設定を間違えたりすると，ドライバ初期化前に死んでしまい，こういう状態になります．)

また，いつもいつでもBitVisor がpanic するとは限りません．
時々ゲストOSだけがpanic したり謎のログを吐いて死ぬことがあります．
ファイルにログを書き出せるような死に方をしてくれれば，いいのですが，そうじゃないことも多いです．
こういう時にログが残せないと困るので，僕はゲストOSであるLinux はシリアルコンソールで操作するようにしています．
シリアルコンソールなら，クライアント側である程度バッファリングでき，それをコピペして残しておくことである程度対処できます．

printf()を入れる方針

何かが思った通りに動かなくて困ったら，printf()でいろいろ情報を表示してみることになります．
どこにprintf()を入れて何を表示するかはデバッグの上で大事なことかと思います．

僕の方針は基本的に「数うちゃ当たる」です．
printf()を入れるとなったら，最初から思いつく場所すべてにprintf()をいれます．

なぜかというと，BitVisor のデバッグではリブートに時間がかかるため，あとで「あ，やっぱりこの情報も表示してみたいな」と思ったときにまたビルドしてリブートしてという作業が必要になり，時間がかかるからです．
それなら，最初から思いつくところすべて書くほうが結果的に速い，ということはよくあります．

ただ，気をつけないといけないこともあります．
printf()はとても重たい処理です．
入れすぎると処理がとても重くなります．
それによって，別の不具合が起きたり，逆に不具合が隠ぺいされてしまったりします．
そのことは念頭に置いておきましょう．

panic() が出力する情報から落ちた場所を察するには

Tips 的なことも紹介してみましょう．
例えばこんなpanic の出力が出たとして

[1444023243.205559] Error: An exception in VMM!
[1444023243.207124] Interrupt number: 0x06 Invalid Opcode Exception (#UD)
[1444023243.208955] CR0: 0x8000003B  CR2: 0x00789C08  CR3: 0xB63E8000  CR4: 0x000026E8
[1444023243.210997] RAX: 0x00000000  RCX: 0x00000000  RDX: 0x00000000  RBX: 0x203F80000
[1444023243.212930] RSP: 0x413FF870  RBP: 0xFFFFFFFF  RSI: 0x413FFD28  RDI: 0x413FF898
[1444023243.214871] R8:  0x00000000  R9:  0x413FFD52  R10: 0x10000000000  R11: 0x00000002
[1444023243.216914] R12: 0xFFFFFFFFFFFFFFFF  R13: 0x00000000  R14: 0x00000000  R15: 0x00000000
[1444023243.218912] ES: 0x0058  CS: 0x0050  SS: 0x0058  DS: 0x0058  FS: 0x0058  GS: 0x0078
[1444023243.220894] CPU0  RSP on interrupt: 0x413FF8C8  Stack information:
[1444023243.222731] +00 RIP     000000004013ADF5  +20 SS  0000000000000058  +40 0000000040126BD0
[1444023243.224819] +08 CS      0000000000000050  +28     000000004013ADF0  +48 0000008128879C00
[1444023243.226880] +10 RFLAGS  0000000000010012  +30     0000000000000400  +50 0000000128879C00
[1444023243.228938] +18 RSP     00000000413FF8F8  +38     00070000401231BC  +58 0000000128879C00
[1444023243.231003] panic(CPU0): int_fatal 0x06 Invalid Opcode Exception (#UD)
[1444023243.232841] CR0 8000003B    CR2 00789C08    CR3 B63E8000    CR4 000026E8
[1444023243.234777] RFLAGS 00000006  GDTR 40347428+0000FFFF  IDTR 401F1580+0000FFFF
[1444023243.236730] stackdump: 0 40347778 0 40124F26 0 40135E1A 40135E38 0 0 D 0 0 40347778 4011EA04 1860 401257F2 0 40125D7C 0 0 0 18 413FF720 413FF6C0 CD62E428B6BC1395 6 4015A998 70F 1860 10E0 4015F440 6
[1444023243.242499] backtrace: 40124F26 40135E1A 40135E38 4011EA04 401257F2 40125D7C 4011E9F2 40126BD0 4013ADF0 4012F3CA 40135DFC 4013ADF5 4013ADF0 40126BD0 40126B55 4013C13B 4013AA40 4013B2A0
[1444023243.248129] Guest state and registers of cpu 0 ------------
[1444023243.249901] RAX 00000000    RCX 00000000    RDX 00000000    RBX FFFFFFFF81600000
[1444023243.251848] RSP FFFFFFFF81601F18    RBP FFFFFFFF8168F160    RSI 00000003    RDI FFFFFFFF81600000
[1444023243.255328] R8  00000000    R9  00000000    R10 FFFFFFED    R11 FFFFFFFF81600000
[1444023243.257306] R12 FFFF88012FDAFBC0    R13 FFFFFFFFFFFFFFFF    R14 000862FA    R15 00000000
[1444023243.259385] CR0 8005003B    CR2 00789C08    CR3 129F99000    CR4 001006F0
[1444023243.261241] ACR   ES 0001C000 CS 0000A09B SS 0000C093 DS 0001C000 FS 0001C000 GS 0001C000
[1444023243.263315] LIMIT ES (2^64-1) CS (2^64-1) SS (2^64-1) DS (2^64-1) FS (2^64-1) GS (2^64-1)
[1444023243.265389] BASE  ES 00000000 CS 00000000 SS 00000000 DS 00000000 FS 00000000 GS FFFF88012FA00000
[1444023243.268878] SEL   ES 00000000 CS 00000010 SS 00000018 DS 00000000 FS 00000000 GS 00000000
[1444023243.270972] RIP FFFFFFFF81014AD3  RFLAGS 00000246  GDTR FFFF88012FA04000+0000007F  IDTR FFFFFFFF8172E000+00000FFF
[1444023243.274562] EFER 00000D01
[1444023243.275993] Exit reason: 52=0x34 (unknown error)
[1444023243.277677] Exit qualification 00000000  VM exit interrupt information 00000000
[1444023243.279652] VM exit errcode 00000000  VMCS IDTR FFFFFFFF8172E000+00000FFF   VMCS RFLAGS 00000246
[1444023243.283063] re=0 pg=1 sw:en=0x0 es=0x0 cs=0x0 ss=0x0 ds=0x0 fs=0x0 gs=0x0
[1444023243.284986] ------------------------------------------------

ご丁寧にError: An exception in VMM! と言っているので，これはBitVisor の中でメモリ操作をミスってるという感じのバグでしょう．
その時に， backtrace: 40124F26 40135E1A 40135E38 4011EA04 401257F2 40125D7C 4011E9F2 40126BD0 4013ADF0 4012F3CA 40135DFC 4013ADF5 4013ADF0 40126BD0 40126B55 4013C13B 4013AA40 4013B2A0 という行を見てみましょう．

これは，panic寸前に実行されたコードのアドレスです．
なので，これがソースコードのどの部分に対応するかわかれば，多少はデバッグの参考になるかもしれません．
このアドレスからソースコードを特定する簡単な方法があります．
以下のコマンドを叩いてみましょう

addr2line -e bitvisor.elf -a 40124F26 40135E1A 40135E38 4011EA04 401257F2 40125D7C 4011E9F2 40126BD0 4013ADF0 4012F3CA 40135DFC 4013ADF5 4013ADF0 40126BD0 40126B55 4013C13B 4013AA40 4013B2A0

addr2line がインストールされてないときは binutils というパッケージをインストールするとよいみたいです(僕がインストールしたときの記憶がもうないので，google 先生に聞いてみたらそう答えてくれました).
bitvisor.elf は実行したのと同じbitvisor.elfを指定します．別のものだと違う結果になってしまいます．
-a の後ろに書いているアドレスは1つでもいいですし，複数でもいいです．
これを実行すると，ずらずらとソースコードのファイル名と行数がでてきます．

追記

@hdk_2 さんからいただいたコメントによると

stackdumpとbacktraceが出ている場合のbacktraceは、単にスタックからコードのアドレスっぽい範囲のものを抽出しているだけの胡散臭いバックトレースです。スタックに残るゴミを拾ってしまうこともあります。コンパイル時にCONFIG_BACKTRACE=1にしておくとよりまともなバックトレースが見られます。(が、64ビットコンパイルであってもフレームポインターが使用されるようになるぶん、パフォーマンスへの影響があります。)

とのこと．
今度試してみよう(まだ試してない).
@hdk_2 さん，コメントありがとうございます．

メモリダンプする方法

BitVisor はpanic するとdbgsh に入れます．
dbgsh ではデバッグをサポートするための機能がいくつかあります．
例えば，メモリダンプを表示することができるので，RSP(スタックポインタ)やCR3が指す先のメモリダンプを表示してみると何か役に立つことがあるかもしれません．
僕も細かい使い方を忘れてしまったのです，以下のようにして使えるはずです
(以下はゲストOSから./dbgshを実行していますが，panic時でも同じだと思います)．

# ./dbgsh
> debug
guest state not found
debug> help
dp guest-physical-address(hex) : dump memory
dv guest-virtual-address(hex) : dump memory
Dp vmm-physical-address(hex) : dump memory
Dv vmm-virtual-address(hex) : dump memory
h value1(hex) value2(hex) : add/sub
r [register-name register-value(hex)]: print/set guest registers
n : get next guest state from log
! command : call external command
q : quit

おわりに

僕がデバッグするときにやっていることなどを書いてみました．
革新的だったり斬新だったりする内容ではないですが，デバッグするときの参考になればよいなと思います．