bochs
OpenBSDの親分Theo de Raadtさんがお怒りです。 OpenBSD on iTWire
Handling of CPU bugs disclosure 'incredibly bad': OpenBSD's de Raadt
その怒りが通じたのか甚大な欠陥が見つかった石、修正するようです。
Intel CEO曰く、Spectre/Meltdown脆弱性をシリコンベースで修正した製品が年内に登場
何たって、強制的に使わされていますからねぇ。原発止めて、もっとやさしいのにしたいって、 世間でせめぎ合ってるのと一緒の構図。
原発止めたって、海の上に風力発電所を作れば、世界中で必要な電力を容易に賄えるとか。どうすか、あーべちゃん、日本の底力を見せつけませんかね。呑気に、2020のオリンピック成功祈願なんかしてる場合じゃないっしょ！
じゃ、石の世界はどうする？ 糞石から逃れるには、オープンソースソフトウェアならぬ、オープンソースハードウェアに限るって事で、公開された物が求められる。
オープン規格の新しい命令セットアーキテクチャRISC-V入門 ツールチェインを用意する
これ、続きが有るようなので期待しましょ。
石のプロトタイプを作るには、FPGAに焼き込むのが楽らしい。そんな事で、未踏スーパークリエーターが、独自CPUを開発してるね。
開発記録が本になって出版されてたんで、取り寄せて昔興味本位で読んでみたよ。もう一度読み直してみるかな。
xv6 on OpenBSD
前回はDebianでxv6をやった。余りリナばかりだとまずいので、BSD系でもやってみる。
$ cc -v OpenBSD clang version 4.0.0 (tags/RELEASE_400/final) (based on LLVM 4.0.0) Target: amd64-unknown-openbsd6.2 Thread model: posix InstalledDir: /usr/bin $ gcc -v Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd6.2/4.2.1/specs Target: amd64-unknown-openbsd6.2 Configured with: OpenBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719
gccは棄て捨てって事で、clangが標準になってるけど、一応昔使われていたgccも残されている。makeはBSD流なので、エラーになるけど、gmakeを使えば、何とか言う事を聞いてくれた。 だが、待てど暮らせど、xv6が起動してこない。だんまりになっちゃうんだ。
gdbでmainにBPを置いて走らせても、mainまで到達していない。はて、何処で止まっているんだか、暴走してるんだか？ 大げさに言うと移植作戦の発動だな。
ソフト屋さんのオシロスコープであるgdbを取り出して、問題を切り分けて行くか。症状から、 カーネルがメインメモリーに載っていない可能性があるな。幸い、前回カーネルのmainが呼び出される軌跡を追っていたので、その復習で復讐だな。
(gdb) b *0x10000c Breakpoint 1 at 0x10000c (gdb) c Continuing. The target architecture is assumed to be i386 => 0x10000c: mov %cr4,%eax Thread 1 hit Breakpoint 1, 0x0010000c in ?? ()
ここまでは信号が来てる。ああ、ハードじゃないんだから、何と言えばいいのやら？ ここからは、丁寧にステップ実行。
=> 0x100020: or $0x80010000,%eax 0x00100020 in ?? () (gdb) => 0x100025: mov %eax,%cr0 0x00100025 in ?? () (gdb) => 0x100028: Error while running hook_stop: Cannot access memory at address 0x100028 0x00100028 in ?? () (gdb) info registers eax 0x80010011 -2147418095 ecx 0x0 0 edx 0x0 0 ebx 0x0 0 esp 0x7bdc 0x7bdc ebp 0x7bf8 0x7bf8 esi 0x10114 65812 edi 0x0 0 eip 0x100028 0x100028 eflags 0x86 [ PF SF ] cs 0x8 8 ss 0x10 16 ds 0x10 16 es 0x10 16 fs 0x0 0 gs 0x0 0
codeで言ったら、entry.Sの
entry: # Turn on page size extension for 4Mbyte pages movl %cr4, %eax orl $(CR4_PSE), %eax movl %eax, %cr4 # Set page directory movl $(V2P_WO(entrypgdir)), %eax movl %eax, %cr3 # Turn on paging. movl %cr0, %eax orl $(CR0_PG|CR0_WP), %eax movl %eax, %cr0 # Set up the stack pointer. movl $(stack + KSTACKSIZE), %esp
stack pointerにセットする所。pagingが有効になった一発目でアクセス違反を犯している。
これって、OpenBSD環境特有な事？ もっと言えば、ハード相当のqemu-system-i386の不具合？ それとも、ソースからバイナリィーを作るソフトウェア系の問題？ 切り分けと言うか、責任分担をきっちりしたいな。そうしないと、互いに罵りあって喧嘩になりますから。
goodby gcc
ならば、小手先で出来るソフトの方から、手を付ける。gccを捨ててclang系にしよう。 gcc特約が付いたMakefileを開いて、gccってなってる所をccに変更。gasも止めてasに変更。
$ gmake cc -fno-pic -static -fno-builtin -fno-strict-aliasing -O2 -Wall -MD -ggdb -m32 -Werror -fno-omit-frame-pointer -fno-stack-protector -fno-pic -O -nostdinc -I. -c bootmain.c cc -fno-pic -static -fno-builtin -fno-strict-aliasing -O2 -Wall -MD -ggdb -m32 -Werror -fno-omit-frame-pointer -fno-stack-protector -fno-pic -nostdinc -I. -c bootasm.S ld -m elf_i386_obsd -N -e start -Ttext 0x7C00 -o bootblock.o bootasm.o bootmain.o objdump -S bootblock.o > bootblock.asm objcopy -S -O binary -j .text bootblock.o bootblock ./sign.pl bootblock boot block too large: 827 bytes (max 510) gmake: *** [Makefile:102: bootblock] Error 1
コンパイルは無事に出来上がったけど、えせMBRはサイズリミットが有って、それに引っかかり ましたとさ。ぱある君のお目付け役が目を光らせていたわい。
ものは試しと、（賄賂を贈って）お目付け役を素通りさせて、コンパイルを先に進めたら
cc -fno-pic -static -fno-builtin -fno-strict-aliasing -O2 -Wall -MD -ggdb -m32 -
Werror -fno-omit-frame-pointer -fno-stack-protector -c -o kalloc.o kalloc.c
cc -fno-pic -static -fno-builtin -fno-strict-aliasing -O2 -Wall -MD -ggdb -m32 -
Werror -fno-omit-frame-pointer -fno-stack-protector -c -o kbd.o kbd.c
In file included from kbd.c:4:
./kbd.h:36:10: error: use of GNU 'missing =' extension in designator
[-Werror,-Wgnu-designator]
[0x1D] CTL,
^
=
./kbd.h:10:25: note: expanded from macro 'CTL'
#define CTL (1<<1)
^
GNUの勝手な拡張って、正にトランプ野郎みたいだな。世界を乱すだけですよ。早く辞めれ！
ってな事で、あえなく撃沈。ならばハードの方から攻めてみるか。qemuに変わるi386な糞石の 真似をするやつ。丁度、前回OSdevで紹介されてたbochsが有るじゃん。
都合が良い事に、OpenBSDでもパッケージが提供されてる。（親分のお眼鏡にかなっているんだな）
Bochs
実行アプリが4.5Mと小粒。後はBIOSのROMとかkeymapが付いてた。インストール後の注意として、/usr/local/share/bochs/bochsrc を、自HOMEに.bochsrcとしてコピーしておくといいよって、思し召しが有った。(このフィイルって工場出荷時の設定条件だな。BTO宜しく、機能追加等をしたい場合、差分を定義すれば良いと思われ)
Welcome to the Bochs IA-32 Emulator Project
あたりが参考になるかな。 説明書と言うか、configファイルが長大なので、どんなデフォルト設定になってるか、炙り出してみた。
$ grep -v '^#' .bochsrc | sed -e '/^$/d' cpu: model=core2_penryn_t9600, count=1, ips=50000000, reset_on_triple_fault=1, ignore_bad_msrs=1, msrs="msrs.def" cpu: cpuid_limit_winnt=0 memory: guest=512, host=256 romimage: file=$BXSHARE/BIOS-bochs-latest, options=fastboot vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest mouse: enabled=0 pci: enabled=1, chipset=i440fx clock: sync=realtime, time0=local private_colormap: enabled=0 floppya: 1_44=/dev/rfd0a, status=inserted ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14 ata1: enabled=1, ioaddr1=0x170, ioaddr2=0x370, irq=15 ata2: enabled=0, ioaddr1=0x1e8, ioaddr2=0x3e0, irq=11 ata3: enabled=0, ioaddr1=0x168, ioaddr2=0x360, irq=9 ata0-master: type=disk, mode=flat, path="30M.sample" boot: disk floppy_bootsig_check: disabled=0 log: /dev/null panic: action=ask error: action=report info: action=report debug: action=ignore, pci=report # report BX_DEBUG from module 'pci' debugger_log: - parport1: enabled=1, file="parport.out" sound: driver=default, waveout=/dev/dsp. wavein=, midiout= speaker: enabled=1, mode=sound
詳しい説明は、同ファイルを見るか、man bochsrc ってのは、お約束事項です。
一応新しいハードの受け入れ試験をやっておくか。
Disk Images with Pre-installed Systems
こちらから、4-megのLinuxを頂いてきた。
展開すると、READMEとアンケート用紙(TESTFOrM.txt)とconfigファイルとイメージが 出て来る。
$ cat bochsrc megs: 32 romimage: file=$BXSHARE/BIOS-bochs-latest vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest vga: extension=vbe, update_freq=15 floppya: 1_44=a.img, status=inserted floppyb: 1_44=b.img, status=inserted ata0-master: type=disk, path=minibootable.img, cylinders=900, heads=15, spt=17 boot: c log: bochsout.txt mouse: enabled=0 cpu: ips=15000000 clock: sync=slowdown
起動は次のようにする。
$ bochs -qf bochsrc
========================================================================
Bochs x86 Emulator 2.6.9
Built from SVN snapshot on April 9, 2017
Compiled on Oct 2 2017 at 16:11:40
========================================================================
00000000000i[ ] BXSHARE not set. using compile time default '/usr/local/share/bochs'
00000000000i[ ] reading configuration from bochsrc
00000000000i[ ] installing x module as the Bochs GUI
00000000000i[ ] using log file bochsout.txt
Next at t=0
(0) [0x0000fffffff0] f000:fff0 (unk. ctxt): jmpf 0xf000:e05b ; ea5be000f0
<bochs:1> c
========================================================================
Bochs is exiting with the following message:
[XGUI ] POWER button turned off.
========================================================================
(0).[387195000] [0x00000010631d] 0010:00000000c010631d (unk. ctxt): cmp dword ptr ds:[ebx+20], 0x00000000 ; 837b1400
pkgから入れたbochsは、内部のdebuggerが有効になってるので、起動直後にdebuggerのメニューが出て来る。ｃすると、VGAな画面が出て来て、リナが起動してく、hdaの割り込みを消失したってエラーが出て、rootのプロンプトまで行かなかった。しょうがないので、電源ボタンを押して、切断したよ。
00794460000p[XGUI ] >>PANIC<< POWER button turned off. 00794460000i[CPU0 ] CPU is in protected mode (halted) 00794460000i[CPU0 ] CS.mode = 32 bit 00794460000i[CPU0 ] SS.mode = 32 bit 00794460000i[CPU0 ] EFER = 0x00000000 00794460000i[CPU0 ] | EAX=00000000 EBX=c01b0000 ECX=c01b0000 EDX=c0199780 00794460000i[CPU0 ] | ESP=c01b1fdc EBP=00009000 ESI=c01b0000 EDI=c01d0820 00794460000i[CPU0 ] | IOPL=0 id vip vif ac vm rf nt of df IF tf sf ZF af PF cf 00794460000i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D 00794460000i[CPU0 ] | CS:0010( 0002| 0| 0) 00000000 ffffffff 1 1 00794460000i[CPU0 ] | DS:0018( 0003| 0| 0) 00000000 ffffffff 1 1 00794460000i[CPU0 ] | SS:0018( 0003| 0| 0) 00000000 ffffffff 1 1 00794460000i[CPU0 ] | ES:0018( 0003| 0| 0) 00000000 ffffffff 1 1 00794460000i[CPU0 ] | FS:0018( 0003| 0| 0) 00000000 ffffffff 1 1 00794460000i[CPU0 ] | GS:0018( 0003| 0| 0) 00000000 ffffffff 1 1 00794460000i[CPU0 ] | EIP=c010631d (c010631d) 00794460000i[CPU0 ] | CR0=0x8005003b CR2=0x00000000 00794460000i[CPU0 ] | CR3=0x00101000 CR4=0x00000090 00794460000i[CMOS ] Last time is 1517245823 (Mon Jan 29 17:10:23 2018) 00794460000i[XGUI ] Exit 00794460000i[SIM ] quit_sim called with exit code 1
xv6で試してみる
bochsで動かすには、PCの設定が必要。qemuスタイルの設定をbochs用に翻訳する必要が有るな。qemuの設定を改めて、分かり易いように書き下すと次のようになる。
qemu-system-i386 -nographic \ -drive file=fs.img,index=1,media=disk,format=raw \ -drive file=xv6.img,index=0,media=disk,format=raw \ -smp 2 -m 512 -S -gdb tcp::26000
なんじゃらほいってのが出て来た。indexって何よ？ 迷わずqemuのmanを見ると
Instead of -hda, -hdb, -hdc, -hdd, you can use:
qemu-system-i386 -drive file=file,index=0,media=disk
qemu-system-i386 -drive file=file,index=1,media=disk
qemu-system-i386 -drive file=file,index=2,media=disk
qemu-system-i386 -drive file=file,index=3,media=disk
index番号でhd(a-d)を決めてるって事かな。取り合えず下記の設定をした。
megs: 512 #cpu: count=2 romimage: file=$BXSHARE/BIOS-bochs-latest vgaromimage: file=$BXSHARE/VGABIOS-lgpl-latest vga: extension=vbe, update_freq=15 ata0-master: type=disk, path=xv6.img, model=flat ata0-slave: type=disk, path=fs.img, model=flat boot: disk com1: enabled=1, mode=null log: log.txt mouse: enabled=0 cpu: ips=15000000
そして、２つのイメージファイルはdisk相当なんで、ちゃんと動くdebianから借りてきた。 smpにすると、ログが煩雑になるんで一つだけにしておいた。(上記cpuのコメントを外すとマルチプロセッサーになる。)
これで起動すると、cpuがbootしたってメッセージが出てからxv6のpanicに遭遇した。 VGAな画面を書き写すと
Booting from Hard Disk... cpu0: starting 0 unexpected trap 119 from cpu 0 eip 80103a74 (cr2=0x0) lapicid 0: panic: trap 8010593f 8010461f 80102e5f 80102f9f 0 0 0 0 0 0
こうなってしまっては、お手上げなので電源をプチィとした。
05404860000i[CPU0 ] CPU is in protected mode (active) 05404860000i[CPU0 ] CS.mode = 32 bit 05404860000i[CPU0 ] SS.mode = 32 bit 05404860000i[CPU0 ] EFER = 0x00000000 05404860000i[CPU0 ] | EAX=00000000 EBX=8010b4bc ECX=00000710 EDX=000003d5 05404860000i[CPU0 ] | ESP=8010b48c EBP=8010b4c4 ESI=8010b4bc EDI=8010b510 05404860000i[CPU0 ] | IOPL=0 id vip vif ac vm rf nt of df if tf sf ZF af PF cf 05404860000i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D 05404860000i[CPU0 ] | CS:0008( 0001| 0| 0) 00000000 ffffffff 1 1 05404860000i[CPU0 ] | DS:0010( 0002| 0| 0) 00000000 ffffffff 1 1 05404860000i[CPU0 ] | SS:0010( 0002| 0| 0) 00000000 ffffffff 1 1 05404860000i[CPU0 ] | ES:0010( 0002| 0| 0) 00000000 ffffffff 1 1 05404860000i[CPU0 ] | FS:0000( 0000| 0| 0) 00000000 00000000 0 0 05404860000i[CPU0 ] | GS:0000( 0000| 0| 0) 00000000 00000000 0 0 05404860000i[CPU0 ] | EIP=801003e3 (801003e3) 05404860000i[CPU0 ] | CR0=0xe0010011 CR2=0x00000000 05404860000i[CPU0 ] | CR3=0x003ff000 CR4=0x00000010
なんか、それらしい設定になってるな。(ちゃんと起動しないのは不本意だけどね。)
続いて、OpenBSDで作ったxv6.imgに変えてみると、bochsのdebuggerが反応したよ。
<bochs:1> c (0).[47147103] ??? (physical address not available) Next at t=47147104 (0) [0x0000fffffff0] f000:fff0 (unk. ctxt): jmpf 0xf000:e05b ; ea5be000f0
ログを見ると、まだ16bitの時代をうろちょろしてる。
00047147104i[ ] dbg: Quit 00047147104i[CPU0 ] CPU is in real mode (active) 00047147104i[CPU0 ] CS.mode = 16 bit 00047147104i[CPU0 ] SS.mode = 16 bit 00047147104i[CPU0 ] EFER = 0x00000000 00047147104i[CPU0 ] | EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000 00047147104i[CPU0 ] | ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 00047147104i[CPU0 ] | IOPL=0 id vip vif ac vm rf nt of df if tf sf zf af pf cf 00047147104i[CPU0 ] | SEG sltr(index|ti|rpl) base limit G D 00047147104i[CPU0 ] | CS:f000( 1e00| 0| 0) ffff0000 0000ffff 0 0 00047147104i[CPU0 ] | DS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00047147104i[CPU0 ] | SS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00047147104i[CPU0 ] | ES:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00047147104i[CPU0 ] | FS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00047147104i[CPU0 ] | GS:0000( 0000| 0| 0) 00000000 0000ffff 0 0 00047147104i[CPU0 ] | EIP=0000fff0 (0000fff0) 00047147104i[CPU0 ] | CR0=0x60000010 CR2=0x00000000 00047147104i[CPU0 ] | CR3=0x00000000 CR4=0x00000000
8.14. Using Bochs internal debuggerを見ながら、debuggerを使って見る。
<bochs:1> b 0x10000c
<bochs:2> c
(0) Breakpoint 1, 0x000000000010000c in ?? ()
Next at t=47147095
(0) [0x00000010000c] 0008:000000000010000c (unk. ctxt): mov eax, cr4 ; 0f20e0
<bochs:3> s
Next at t=47147096
(0) [0x00000010000f] 0008:000000000010000f (unk. ctxt): or eax, 0x00000010 ; 83c810
(0) [0x00000010001d] 0008:000000000010001d (unk. ctxt): mov eax, cr0 ; 0f20c0
:
<bochs:8>
Next at t=47147101
(0) [0x000000100020] 0008:0000000000100020 (unk. ctxt): or eax, 0x80010000 ; 0d00000180
<bochs:9>
Next at t=47147102
(0) [0x000000100025] 0008:0000000000100025 (unk. ctxt): mov cr0, eax ; 0f22c0
<bochs:10>
Next at t=47147103
(0).[47147103] ??? (physical address not available)
糞石のセグメント関係を確認出来るとな。こんな機能はgdbに有ったかなあ？ 丁寧に糞石の 挙動を再現してるからこそ出来る技なんだろうね。
<bochs:11> sreg
es:0x0010, dh=0x00cf9300, dl=0x0000ffff, valid=31
Data segment, base=0x00000000, limit=0xffffffff, Read/Write, Accessed
cs:0x0008, dh=0x00cf9b00, dl=0x0000ffff, valid=1
Code segment, base=0x00000000, limit=0xffffffff, Execute/Read, Non-Conforming, Accessed, 32-bit
ss:0x0010, dh=0x00cf9300, dl=0x0000ffff, valid=31
Data segment, base=0x00000000, limit=0xffffffff, Read/Write, Accessed
ds:0x0010, dh=0x00cf9300, dl=0x0000ffff, valid=11
Data segment, base=0x00000000, limit=0xffffffff, Read/Write, Accessed
fs:0x0000, dh=0x00001000, dl=0x00000000, valid=0
gs:0x0000, dh=0x00001000, dl=0x00000000, valid=0
ldtr:0x0000, dh=0x00008200, dl=0x0000ffff, valid=1
tr:0x0000, dh=0x00008b00, dl=0x0000ffff, valid=1
gdtr:base=0x0000000000007c60, limit=0x17
idtr:base=0x0000000000000000, limit=0x3ff
そして、こちらは、コントロール関係のレジスタ類。
<bochs:12> creg
CR0=0xe0010011: PG CD NW ac WP ne ET ts em mp PE
CR2=page fault laddr=0x0000000000000000
CR3=0x00000010a000
PCD=page-level cache disable=0
PWT=page-level write-through=0
CR4=0x00000010: pke smap smep osxsave pcid fsgsbase smx vmx osxmmexcpt umip osfxsr pce pge mce pae PSE de tsd pvi vme
CR8: 0x0
EFER=0x00000000: ffxsr nxe lma lme sce
面白い事にこのdebuggerはtrace of/off が出来る。（そんなのをschemeは仕様で要求してたな）でも、何も考えずに設定すると、膨大なログが出てくるぞ。Next at t=47147095 って、 これだけの命令を電源投入時から実行したって事だからね。
debugger_log: debuggr.out
どうしてもやりたかったら、こんな設定をconfigに書いて、ログに落とすのが吉。
bochs on debian
調子ののってdebianにもbochsを入れてみた。デフォで入れるとbochs-wxが付いてくる。お客様OSには、古いOpenBSDを選んだ。（何たって、フロッピーディスク１枚分ですからね。）
起動したら、Xのライブラリィーが無いと言われてbochsの起動を拒まれてしまった。追加で、bochs-xも入れてあげたよ。そしたら機嫌よく動いてくれた。
よく見るOpBSDの起動メッセージがつらつらと出て来て、login画面に行くかと思ったら、 インストールするかアップデートするかシェルに落ちるか選べですって。まあ、フロッピー１枚で、フルスペックのOpenBSDが動くわけないよなと、苦笑い。（傍からみたら、かなり不気味でしょう）
迷わずshellに落ちたよ。落ちたはいいけど、大した事は出来ない。しょうがないので、bochs側で待機してるdebuggerに働いてもらおう。
Ctl-Cすると、眠っていたdebuggerが起きてくる。そこで
<bochs:7> info tab cr3: 0x0000000000420000 0xdff7f000-0xdff7ffff -> 0x0000000000420000-0x0000000000420fff 0xdff80000-0xdfffefff -> 0x0000000000423000-0x00000000004a1fff 0xdffff000-0xdfffffff -> 0x00000000011b9000-0x00000000011b9fff 0xe0100000-0xe04a1fff -> 0x0000000000100000-0x00000000004a1fff : 0xe3ec3000-0xe3ec3fff -> 0x000000000111c000-0x000000000111cfff 0xfff7f000-0xfff7ffff -> 0x00000000011b9000-0x00000000011b9fff 0xfff80000-0xffffefff -> 0x0000000000423000-0x00000000004a1fff
Show paging address translationを確認してみた。
<bochs:8> creg
CR0=0xe001003b: PG CD NW ac WP NE ET TS em MP PE
CR2=page fault laddr=0x0000000000220004
CR3=0x0000000000420000
PCD=page-level cache disable=0
PWT=page-level write-through=0
CR4=0x00000000: smep osxsave pcid fsgsbase smx vmx osxmmexcpt osfxsr pce pge mce pae pse de tsd pvi vme
CR8: 0x0
EFER=0x00000000: ffxsr nxe lma lme sce
CR3からの物理アドレスをアクセスしてみたけど、データが入っていないなあ。見てる所が違う？ もう少し探求してみよう。
<bochs:20> xp/16x 0x0000000000420000 [bochs]: 0x0000000000420000 <bogus+ 0>: 0x00000000 0x00000000 0x00000000 0x00000000 0x0000000000420010 <bogus+ 16>: 0x00000000 0x00000000 0x00000000 0x00000000 0x0000000000420020 <bogus+ 32>: 0x00000000 0x00000000 0x00000000 0x00000000 0x0000000000420030 <bogus+ 48>: 0x00000000 0x00000000 0x00000000 0x00000000
debugger_logのフォーマットって指定出来ないのかな。一般用は、下記のように設定出来るみたいだけど。（debuggerを友とするような人は、自分でHackしろって事だな）
4.3.25. logprefix
Examples:
logprefix: %t-%e-@%i-%d
logprefix: %i%e%d
This handles the format of the string prepended to each log line. You may use those special tokens :
%t : 11 decimal digits timer tick
%i : 8 hexadecimal digits of current cpu eip (ignored in SMP configuration)
%e : 1 character event type ('i'nfo, 'd'ebug, 'p'anic, 'e'rror)
%d : 5 characters string of the device, between brackets
Default is %t%e%d