カーネルデバッグの話はここで存分にどうぞ

age

1.http://oss.sgi.com/projects/kdb/ より、使用しているカーネルにあった
　パッチをダウンロードし、カーネルソースにパッチを当てる。
2.make xconfigなりのカーネルコンフィグアプリを起動。
　Kernel Hackingの項目が追加されているので、
　"Build-in Kernel Debugger support"をyにする。ついでに
　"compile the kernel with frame pointers"もyにしたほうがスタック
　トレースがとりやすくなる。
3.カーネル再構築。
4.lilo.confに以下のように"kdb=on"のカーネルブートオプションをつける。
>image=/boot/vmlinuz-2.4.4-test
> label=test
> read-only
> root=/dev/hda2
> append="kdb=on"
5.liloを実行し、ブート情報を書き込み、ブートオプションをつけたカーネルから
　ブート。
6.Pauseキーを押すとカーネルデバッガに入る。"g"コマンドで再開。

リモートの場合。
1.同じくクロスシリアルケーブルを用意しターゲットとターミナルを繋ぐ。
2.ターミナルマシン上で適当なターミナルプログラムを起動する。
3.liloのappendコマンドを以下のように変更。
　append="kdb=on console=ttyS0,38400"
　これで、シリアルコンソールにデバッガの出力が表示される。
　停止はターゲットでPauseキーか、ターミナルでCTRL-A。
4.ただこれだと、ブートメッセージがターミナルにしか表示されなく
　なるので、以下のようにしたほうがいいかも。
　append="kdb=on console=ttyS0,38400 console=tty0"
　これで、ブートメッセージは両方に出力される。そのかわりCTRL-Aでの
　Breakinはできなくなる。
　Initは最後に指定されたコンソールに出力するらしく、
　append="kdb=on console=tty0 console=ttyS0,38400"
　のようにしてしまうとInitの出力がターミナルだけになってしまうため
　不便。

とりあえず、Linuxカーネルのなかで実際に止めてみて、どんな感じになるか見てみよう。
えっと、とりあえずSGI KDBは動いてるとします。で、なんかユーザーが特定の
操作をやったらとまる場所を探そう。俺が今回使うのはipv4のicmpのコード。
ユーザーがping叩けばそこ必ずとおるからね。普段はあまり通らないから変に
たくさん止まることもないと。
ソースをみていい止める関数を探してもいいが、今回俺はsystem.mapを使った。
system.mapをエディタで開いてみるとこんな感じでicmpがらみの関数がある。
c0206a60 t icmp_reply
c0206be0 T icmp_send
c0206f60 t icmp_unreach
c0207220 t icmp_redirect
c02072d0 t icmp_echo
c0207320 t icmp_timestamp
c0207410 t icmp_address
c0207420 t icmp_address_reply
c0207570 t icmp_discard
c0207580 T icmp_rcv
icmp_unreachなんかがいいかね。多分icmpが届かなかった場合にくるファンクション
だろう。はい、ターゲットマシンでPauseキーを押してbreakinしましょう。
[1]kdb>　とかいうプロンプトがでるな。最初の数字はプロセッサナンバーだ。
シングルプロセッサで動かしてるなら常に0になる。
で、icmp_unreachにbreakpoint張るわけだが、system.mapを見て
[1]kdb> bp c0206f60　とじかにアドレス指定してもいいんだが、もっと簡単に
[1]kdb> bp icmp_unreach　とシンボルを指定してもできる。
うまくbreakpoint張れたら
Instruction(i) BP #0 at 0xc0206f60 (icmp_unreach)
is enabled globally adjust 1
とか出るはず。あと、とりあえず、breakpoint張る前に実際のそのアドレスが
ファンクションの先頭であるか確認したほうがいいな。
ディスアセンブルはidコマンドだ。
[1]kdb> id icmp_unreach
0xc0206f60 icmp_unreachpush %ebp
0xc0206f61 icmp_unreach+0x1mov %esp,%ebp
0xc0206f63 icmp_unreach+0x3mov $0x14,%eax
0xc0206f68 icmp_unreach+0x8push %edi
0xc0206f69 icmp_unreach+0x9push %esi
0xc0206f6a icmp_unreach+0xapush %ebx
こんな風に先頭2インストラクションが push %ebpとpush %esp,%ebp　ならそれは
まず間違いなく関数の先頭だ。これはC言語のStackFramを作るコードだ。

breakpointが張れたらgコマンドで再開。icmp_unreach関数を呼ぶために
適当な存在しないipアドレスへpingを送ってみよう。
breakpointにHitしたら
Instruction(i) breakpoint #0 at 0xc0206f60 (adjusted)
0xc0206f60 icmp_unreachint3
Entering kdb (current=0xc1228000, pid 0) on processor 1 due to Breakpoint @ 0xc0206f60
のようなメッセージが出てコマンド待ちになる。
なにはともかく。止まったらスタックバックトレースを取ろう。コマンドはbtだ。
[1]kdb> bt
EBP EIP Function(args)
0xc1229e5c 0xc0206f60 icmp_unreach (0xc01051b0, 0xffffe000, 0xc1228000, 0xc1228000, 0xc1228000)
kernel .text 0xc0100000 0xc0206f60 0xc0207220
0xc0106fac ret_from_intr
kernel .text 0xc0100000 0xc0106fac 0xc0106fcc
Interrupt registers:
eax = 0x00000000 ebx = 0xc01051b0 ecx = 0xffffe000 edx = 0xc1228000
esi = 0xc1228000 edi = 0xc1228000 esp = 0xc1229fac eip = 0xc01051df
ebp = 0xc1229fac xss = 0x00000018 xcs = 0x00000010 eflags = 0x00000246
xds = 0xc1220018 xes = 0xc1220018 origeax = 0xffffff00 ®s = 0xc1229f78
0xc01051df default_idle+0x2f
kernel .text 0xc0100000 0xc01051b0 0xc01051f0
0xc1229fc0 0xc0105272 cpu_idle+0x52
kernel .text 0xc0100000 0xc0105220 0xc0105290
うーん、なんかうまく取れてないね。StackFrameがちゃんと作られてないと
完全には取れないんだね。でも関数の頭を見る限り全部StackFrameは
作られてるんだけどね。謎だ。KDBのソースを見て調べてみるしかないね。

うまくスタックトレースが取れないから、ssコマンドを使ってトレースを
しながら、breakpointをうまく張って上位の関数に戻っていくと、
ip_rcv->icmp_unreachと来ていることがわかる。さらにトレースすると、以下の
トレースが取れるようになる。
#[1]kdb> bt
# EBP EIP Function(args)
#0xc1229e74 0xc01e92bf ip_run_ipprot+0x3f (0xc191fb60, 0xc76cdc70, 0xc030e108, 0x1, 0x1)
# kernel .text 0xc0100000 0xc01e9280 0xc01e92e0
#0xc1229eac 0xc01e93f6 ip_local_deliver+0x116 (0xc01051b0, 0xffffe000, 0xc1228000, 0xc1228000, 0xc1228000)
# kernel .text 0xc0100000 0xc01e92e0 0xc01e9460
# 0xc0106fac ret_from_intr
# kernel .text 0xc0100000 0xc0106fac 0xc0106fcc
#Interrupt registers:
#eax = 0x00000000 ebx = 0xc01051b0 ecx = 0xffffe000 edx = 0xc1228000
#esi = 0xc1228000 edi = 0xc1228000 esp = 0xc1229fac eip = 0xc01051df
#ebp = 0xc1229fac xss = 0x00000018 xcs = 0x00000010 eflags = 0x00000246
#xds = 0xc1220018 xes = 0xc1220018 origeax = 0xffffff00 ®s = 0xc1229f78
# 0xc01051df default_idle+0x2f
# kernel .text 0xc0100000 0xc01051b0 0xc01051f0
#0xc1229fc0 0xc0105272 cpu_idle+0x52
# kernel .text 0xc0100000 0xc0105220 0xc0105290
これで、大体のコードの流れがわかる。

ちょっとレジスタをいじって、不正処理を起こしてみよう。
とりあえず、bc *　コマンドで設定した全てのbreakpointを消して、再実行。
で、pingコマンドを終了。しばらくまってicmpの処理が終わったのを待って、
icmp_unreachに再度breakpointを設定。ping実行。ssコマンドを使って
icmp_unreach+0x18までステップトレース。次の命令はこの命令のはず。
0xc0206f78 icmp_unreach+0x18mov 0x5c(%edx),%ebx
これで、edxに0を入れれば当然不正処理が起きる。rm edx 0 でedxに0が入る。
確認はrdコマンドで出来る。edxに0が入ったことが分かったらgコマンドで再実行。
[0]kdb> g
Unable to handle kernel NULL pointer dereference at virtual address 0000005c
printing eip:
c0206f78
*pde = 00000000

Entering kdb (current=0xc0312000, pid 0) on processor 0 Oops: Oops
due to oops @ 0xc0206f78
eax = 0x00000014 ebx = 0xc226d0a0 ecx = 0x00000008 edx = 0x00000000
esi = 0xc1aeaea4 edi = 0xc7536c00 esp = 0xc0313e30 eip = 0xc0206f78
ebp = 0xc0313e58 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc0313dfc
のようなメッセージを出して止まるはず。メッセージより、0xc0206f78のコードが
0x5c番地をアクセスして不正処理で止まったことがわかる。[0]kdb> id %eip とすれば
0xc0206f78 icmp_unreach+0x18mov 0x5c(%edx),%ebx
とでるから、edx=0が原因となったことがわかる。

あとは俺は基本的にsage進行。オリジナルスレは適当にうっちゃってsage out
させてくれ。

○岡さん？>>別スレ１

俺は自分のwebページも持ってない、しがない一プログラマです。だから誰も
知らないでしょう。

kernel毎刺さってるときって、どうデバッグすればいい?
再現出来ないときがほとんどだし、めったにでないけど。
ダンプとかってとれるのかな。

>>1
うにゅースマソ
ほとんど同じ草稿を見たことあったもんだから、勘違いした

KDBがonになっていれば、コードが無限ループになっている場合は普通に
pauseキーでbreakinすれば回ってる場所で止まるはず。マルチプロセッサに
すれば、確実に止まるね。cpu 0が無限ループしてもcpu 1がbreakinの処理を
行えるから。
コードが無限ループしているわけじゃなくてシンクロナイズリソースで止まって
る場合はちょっと面倒。多分btaで全プロセスのスタックを取って怪しいリソースを
見つけてそれの待ち行列リストからたぐっていくしかないんじゃないかな。

ダンプを取れるカーネルは同じくSGIが提供してる。使ったこと無いけど。
基本的にダンプがあっても、そうとう運がよくないとトラブルシュートできない
からね。下手にダンプがあると、素人さんが「ダンプがあるからなんでもできるだろ」
と思い込むから危険。すでに稼動しているシステムだとかなり難しいんだけど、
それでもライブでデバッグできるような状況にもっていくのが重要かな。

>>14
なるほど。サンクス。

結局1はどうしたいのさ？
2chでお山の大将になりたいの？まあそれにさえ失敗してるけどね。
MLへ行くなりKernel Debug Mini-HOWTO書くなりした方が尊敬されると思うよ。
まあここが1がやっと見つけた居場所なら何も言わないけどな。
いろんなスレで叩かれたり相手にされなくなったりしたみたいだから。

>>17
君、つまらんよ。

うーん、どうやっても煽られるのね。みなまで書かんとわからんか。
前のスレを立てた動機はこの板で「Win2Kは落ちる」だと書かれることが
多いから、真実を知るために立てた。Win板やUNIX板に立てなかったのは
それらの板では落ちるなどということは書かれることが殆どなかったからだ。
その後Linux専用で立てろという意見があり、誰かが新スレを立てれば俺は
そっちに移ると言った。そしたら誰かが新スレを立てたから言った通り俺は
ここに移ってきて、Linux専用の内容をここにコピペしたまでだ。
お呼びでないなら、適当にうっちゃってsageてくれ。

うん、1の言う事は間違ってない。
Win2Kは落ちるとろくに使ってもない奴がいうのは間違い。
まあ、それでもいろんなとこで落ちるとか不具合の話を
聞くのは何故だか知らないが(藁
しかし、素直に1の技術力には感心するな、

1=別スレの1=18

>>21
ぶー、ハズレ。

age

これはあげよう

1=別スレの1=18=20=22

めっちゃわかりやすい。

さすが妄想力。おみそれしました。

結局1はどうしたいのさ？
2chでお山の大将になりたいの？まあそれにさえ失敗してるけどね。
MLへ行くなりKernel Debug Mini-HOWTO書くなりした方が尊敬されると思うよ。
まあここが1がやっと見つけた居場所なら何も言わないけどな。
いろんなスレで叩かれたり相手にされなくなったりしたみたいだから。

前スレの1みたいな、自分のオタク趣味のひけらかしなんぞ、
誰も求めていません。てゆうかウザイだけです。

大体そんなマニア的過ぎる偏った知識なんて、実際の仕事じゃ
何の役にも立たないっての。それこそ、そんだけ詳しいんだっ
たら、UNIXカーネルの作り方のコツとか教えてくれた方がよほど
まともだぜ。

>>27
オレはこのスレッドは保存してるよ
便利だし（すっげー読みにくいけど）

>>83
おれアニオタじゃないのだが、「ちょっとなら」そういうネタを
入れてもいいと思う。それが一種彼らの楽しみでもあるわけだしさ。
逆にアニメじゃなくても、趣味の押しつけがましい
ドキュメントやサンプルがあったら引くわな。
何事も程度の問題ってことで。

>>26
あれ？
嵐君はこのスレと何か関係あるの？
墓穴掘ってるよ。

名スレの予感

>>25
ぶー、やっぱりハズレ。

>>28
カーネルの再構築の仕方なんて検索すれば腐るほどでてくるじゃん。
それにあれただ単にmakefileを決まった引数つけて実行させてるだけでしょ。
あんなの誰でも出来るぞ。コツも何もあったもんじゃない。
うまくいかなかったらmakefileを読みなさい。
他のページに書かれてないことを書くほうがよっぽど有用だろ。君が有用で
ないと思うのはこういうデバッグを必要とするような事をしてないからだよ。
実際ドライバを書いたりすればカーネルデバッガが非常に有用なのが分かるよ。
Winのこととは関係ないことかいてるのになんで煽るのかな。君、個人的に
なんか俺に恨みあるの？前スレで突っかかってきた奴がまだ粘着してるわけじゃ
ないよな。

>>35
前スレでセルフでカーネルデバッグの質問した人です。
あんときはどうも。

自力で解決できたんであの方法まだ使ってないけど
そのうち使わせてもらいます。

敵が多いけど頑張ってね。

>>35
暇があったらオリジナルの方にもまた有用なカキコお･ね･が･い♪

>>35
誰も再構築の話なんて訊いていませんけど?
てゆうか、なんでカーネルの作り方＝カーネルの再構築に
なるんだよ? 凄い脳内変換だねえ、やっぱお前バカだわ。

大体他のページで書かれていない事で有用なのがカーネルの
デバッグなわけ? 有用なのはお前のオタク趣味にとってだろ。
しかもカーネルのデバッグが仕事で有用? そんなのお前の
仕事だけだよ。普通のエンジニアやプログラマーはそんな
面倒なことはしないで、もっと別の解決方法を考えるに決ま
ってんだろ。

>>38
あなたの意見はとても偏見に満ちています。
それは、カーネルにはまだまだバグが多く潜んでいることを
知らないということが原因です。

また、デバイスドライバの開発は、すなわち、カーネルの開発です。
デバイスドライバのデバッグは、すなわち、カーネルのデバッグです。

>カーネルにはまだまだバグが多く潜んでいる

そんなことくらいは知っている。
ただ、カーネルのデバッグなんてとんでもなく時間がかかる作業を
自分の仕事にしている人はかなり限られる。少なくともエンジニアや
プログラマーの大多数を占める、システムの構築や運用・管理、モジ
ュールの設計・コーディングをやっている人間がこんなことに手を出す
とはとても思えん。

>デバイスドライバの開発は、すなわち、カーネルの開発
>デバイスドライバのデバッグは、すなわち、カーネルのデバッグ

そんなわけねえだろ(ｗ

>>40
ご理解いただけず、とても残念です。

>>40
> ただ、カーネルのデバッグなんてとんでもなく時間がかかる作業を
> 自分の仕事にしている人はかなり限られる。少なくともエンジニアや
> プログラマーの大多数を占める、システムの構築や運用・管理、モジ
> ュールの設計・コーディングをやっている人間がこんなことに手を出す
> とはとても思えん。

仕事と決めつけるのはなぜ？趣味でやる人は依然多いと思うけど？
少なくとも、デスクトップのテーマがどうとか、最強のウインドウマネージャとか
いう話題よりもはるかに有益だと思うけど。

> >デバイスドライバの開発は、すなわち、カーネルの開発
> >デバイスドライバのデバッグは、すなわち、カーネルのデバッグ
>
> そんなわけねえだろ(ｗ
そんなわけあるよ。

>>38
あ、カーネルの作り方ね、本当にカーネル作りたいんだ。だったら本当に
カーネルデバッガ必要だね。ライブの動きを見ながらソースを追うのが
一番理解が深まるよ。

>>40
何なんだこのLin厨の世間知らず振りは。

>>42
>仕事と決めつけるのはなぜ？

別に決めつけてねえよ、よく読め。

>趣味でやる人は依然多いと思うけど？

だからそんなヲタクの為のオナニースレはLinux板にいらねえって
言ってんだよ。やたら詳しいけど、同時にものすごく偏っていて、
実務的でもなければ学術的でもない知識をひけらかす。そもそも
ソフトにバグがあるのは当たり前。そのうち致命的な物については
発見されたらその都度パッチを貼り、そうでないものについては
だましだまし使うのがまともなユーザー。それをまるで完璧なもの
を求めるかのようにネチネチとイジるなんて、やってることが極めて
非生産的&病的。それこそセキュリティの弱いサーバーをクラック
して遊ぶ外道と大して変わらねえよ。

>>45
申し訳ないけど、このスレの情報が役に立っている人もいるんだ。
スレを汚さないでほしいんだが・・・
あと、パッチを貼ったりしているなら、そのパッチを作った人達にも
ほんの少しでもいいから敬意を払ってはくれまいか？ たのむよ・・・

仕事してるふつーの技術者は2ch見てくだらん煽りいれてる暇があったら
他にすることがあることくらい知ってるでしょう。

ｳﾞｧｶはほっとくのが吉。

>>45
これがLinuxユーザーの認識なのか？
信じたくはないが…

>>48
>>45は際立ってバカだけど、でも大抵のビジネスユーザは、
「会社に指示されて」使うわけだからあんなものかも。

知的好奇心や向上心を持たない技術者なんて珍しくもない。

「知的好奇心」や「向上心」の現れ＝カーネルデバッグ?
こりゃまたとんでもない勘違いだね。