gdbによるqemuデバッグ

注意(&概要)

ここで解説するのは、カーネルのデバッグではない。一般的な「gdbによるカーネルデバッグ」とは、gdbでカーネルをデバッグする事を指し、カーネルのソースコード上にブレークポイントを仕掛けるわけだが、今回説明するのはそれとは違うので、混同しないように。

今回解説するのは、「『カーネルを走らせているqemu』をgdbでデバッグする」方法である。まあ広義で言えばカーネルのデバッグと言えなくもないが、あくまでデバッグ対象はqemuである。

こんな回りくどいデバッグ方法は、主にハードウェアのデバッグで役立つ。例えばデバイスドライバを書く場合、自作デバイスドライバがQEMU上でさえ動かない事がある。デバイスドライバが動かずにエラーとなる場合、大抵フラグの設定方法が間違っていたり、初期化ロジックが違ったりするわけだが、どこのフラグの設定が悪さをしてデバイスをInvalid Stateにしているかは、カーネルをずっと睨んでいても分からない。そんな時に、デバイスの中を覗く手段として、QEMUのデバッグが役に立つ。

手順

まず、qemuを走らせる。特に指定すべきオプションはない。

qemuを起動後、できる限り早くコンソールからstopを叩いて、エミュレーションを止める。

次に、psコマンドからqemuプロセスを探す。親子関係になっている二つのqemuプロセスが見つかると思うが、「子供のほう」のpidを控える。

その上で、gdbを立ち上げる。rootで実行するのを忘れないように。

# gdb -p

gdbのコンソールが立ち上がったら、qemuのソースコードのハードウェアエラーを検出してそうな所にブレークポイントを仕掛ける。ついでに以下も叩いておくと良い

(gdb) handle SIGUSR1 noprint

あとは、gdbでcontinueからのqemu上でもcontinueする事で、ブレークポイントが正しければいずれ引っかかるはずだ。

 

実際にデバッグした時の思考プロセスを書いたので、こちらもどうぞ

時折飛んでくる原因不明な#GPをgdbで原因究明した備忘録

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中