CTKアプリのデバッグ
出典: CTK: Cell ToolKit Library
「メインページ」に戻る / 「CTKユーザマニュアル」に戻る
以下で書かれている内容は、CTKを使っていない場合でも当てはまります。つまり、Cell SDK環境でCellプログラムをデバッグするのに共通な内容となっています。
目次 |
[編集]
デバッガでプログラムを追うのに必要な共通の準備
- まず、通常のプログラムをデバッグするときと同様、PPEプログラムもSPEプログラムも -g オプションをつけてコンパイルしてください。
$ ppu-gcc -g -c `ctk-config --ppu-cflags --ppu-ldflags --ppu-libs` \ ppe-test.o -o ppe-test $ spu-gcc -g -c `ctk-config --spu-cflags --spu-ldflags --spu-libs` \ spe-test.c -o spe-test
- apps ディレクトリ以下のサンプルコードをデバッグする場合、各ディレクトリ以下のMakefileで PPU_CFLAGS = -g という行を、またさらにそのサブディレクトリ spe 以下の Makefile で SPU_CFLAGS = -g という行を追加すればコンパイルオプションとして指定できます。
- すべてのサンプルをデバッグ可能なようにコンパイルしたい場合、apps/make.header の末尾に以下の2行を追加してください。ここでの指定は全サンプル (rtrace_ctk と mandel_movie をのぞく) で有効となります。
PPU_CFLAGS = -g SPU_CFLAGS = -g
[編集]
Cell SDK 2.X 環境でCTKアプリのSPEプログラムをデバッガで追う
- Cell SDK 2.X以降がインストールされているPS3やIBMのCell環境では、
PPU用のデバッガppu-gdbがcombined debuggerとなっており、 ppu-gdbを使うことでPPEプログラムやそのプログラムから実行されるSPEプログラムをシームレスに追うことができます。
- ppu-gdb を使ってPPEプログラム側を開始したら、通常のプログラムのようにブレークポイントなどを設定して run で実行を開始してください。SPEプログラム内のシンボルなどをbreakpointに設定すると、プログラムが読み込まれるまでbreakpointの設定をペンディングするか聞かれますので、yと答えます。
$ ppu-gdb your-ppe-program GNU gdb 6.6 ... (gdb) break some_spe_function Function "some_spe_function" not defined. Make breakpoint pending on future shared library load? (y or [n]) y (gdb)
- ブレークポイントで実行が止まったら、SPEプログラムを実行中でも普通に list でSPEのソースを見たり step で実行を進めたりすることができます。
[編集]
SPEプログラム開始時に実行を止めてデバッガに戻すには
- 特定のブレークポイントではなく、SPEプログラムが開始されたときに実行をとめたい場合は set spu stop-on-load をセットしてから runしてください。
(gdb) set spu stop-on-load
(gdb) run
...
[Switching to Thread XXXXXXX (LWP XXXX)]
0x000XXXX in main (speid=xxxxxxxxxxx, argv=xxxxxxxxxxxx)
at spe-xxx.c: 8
8 {
(gdb)
[編集]
SPE実行中のDMA転送バグによるBus errorを調べるには
- info spu dma というコマンドを使って、SPEのDMA実行キューのそのときの様子をみることができます。
(gdb) run
Starting program: ...
...
Program received signal SIGBUS, Bus error.
[Switching to Thread XXXXXXX (LWP XXXX)]
0x0000XXXX in ?? ()
(gdb) info spu dma
Tag-Group Status 0x00000002
Tag-Group Mask 0x00000001 ('all' query pending)
Stall-and-Notify 0x00000000
Atomic Cmd Status 0x00000000
Opcode Tag TId RId EA LSA Size LstAddr LstSize E
putllc 0 0 0 0x0000000010012100 0x3fd80 0x00000
get 0 0 0 0x00000400002e2084 0x08980 0x00010 *
get 0 0 0 0x0000000010011e00 0x08980 0x00000
mfcsync 0 0 0 0x00300 0x00880
...
- ちょうどそのとき実行されていたDMAコマンドがあれば、該当するコマンドの行の右端にアスタリスク * がついて表示されます。実行中のDMA実行コマンドの EA (メインストレージのEAアドレス) や LSA (LSアドレス)、Size (転送サイズ) をチェックして、アラインメントなどがおかしくないか調べることができます。
- 例えば上の例では上から2行目の get コマンドにおけるEAの値が16バイトにアラインされていないことがわかります。したがって、Bus error の起きた原因はDMAコマンドのアラインメントエラーであると推測できます。
[編集]
Cell SDK 1.X 環境でCTKアプリのSPEプログラムをデバッガで追う
- Cell SDK 1.XがインストールされているPS3やIBMのCell環境では、環境変数 SPU_DEBUG_START を設定してPPE側のプログラムを実行することで、そのプログラムから実行されるSPEプログラムをデバッガ spu-gdb で追うことができます。
- SPU_DEBUG_STARTを設定してプログラムを実行すると、SPEプログラムの実行が開始されるタイミングで次のような表示が出ます。(このとき、プログラム実行時にコマンドラインの最後に & をつけてプログラムがバックグラウンドで実行されるようにしておくと、SPEのデバッガを同じターミナルで起動することができます)
$ env SPU_DEBUG_START=1 ./program & Starting PSE thread 0xXXXXXXXX, to attach debugger use: spu-gdb -p XXXXX
- 表示どおりのコマンドラインを実行することでSPEプログラムをSPU用のgdb (spu-gdb)で追うことができます。(XXXXXの部分の表示は実行毎に違います)
$ spu-gdb -p XXXXX
- 複数のSPEスレッドを実行している場合、複数行表示が出ます。アタッチしたいスレッドを選んでspu-gdbを実行してください。
- なお、ここに書かれているデバッグ方法は、基本的にはlibspe1環境におけるデバッグ方法と同等(CTKを使っていてもいなくても)です。
