かなり手こずった。
C級出版の付録Cortex-M3開発ボードを手にして、直ぐに具体的な開発（という名のお遊び）に取りかかれると思ったのに、意外と大変だったワイ。ちなみに目標はSDカードへのFATファイルシステムアクセスをモノにすること！！
とりあえず、interface誌にならってbintuils、GCC、GDBをインストールしてコンパイルするのは無問題。GDBのスタブもinterface誌にあるものを流用して、とりあえずはターゲットとconnectしてダウンロードとかCtrl+Cでブレークするところまでは直ぐに確認できた。しかし、ここからが長かった・・・
まず、's'でステップ実行ができない！'s'でも'c'でも同じようにLEDチカチカが走り続けてしまう。なんでだ？
'b'でbreakpointを張ってみる。とりあえず、止まるのだが訳の分からないところで止まっている。アドレスから見るとGDBスタブの中で止まっているように見えるな。なんでだ？
では、ソフトの方にBKPT命令を入れてGDBでキャッチできるかどうか見てみよう。とりあえず止まる。が、やはりbreakpointを張ったときと同じように、スタブの中で止まっているように見える。breakはできないのか？GDBの意味無いじゃん！なんでだろう？
まあよい、'c'でcontinueはできるはずだ。Ctrl+Cでブレークした時はstepはできなくてもcontinueはできていたんだ。breakpointの続きから実行再開してくれるはず・・・、あれっ？しないな～。同じアドレスで止まったままGDBに戻ってくるな。なんでだ？
ここから堂々巡り。
GCCは正式にはthumb2命令には対応していないらしく、ややこしいことにCortex-M3はthumb2命令しか対応していないため、ARMモードに戻るようなコードは御法度！。何か変なコードが紛れ込んでるのかと思って、GDBからdisassembleしてみるとどうもおかしい。thumb命令って基本16bit長じゃなかったっけ？逆アセの結果は全部32bit単位で出てる。メモリの内容がおかしいのか、それとも・・・「GDBがthumb2のデバッグに対応していない！」なんてオチなのか？そんなことはあるまい。
しかし確かにdisassembleの結果はおかしい。ダウンロード前のelfバイナリをobjdumpすればちゃんとthumb2で逆アセされてるから、おかしなコードがあるわけでもないようだ。困った困った・・・
それからも、いろいろ紆余曲折した挙げ句に分かった原因は・・・。
interface誌のGDBスタブが間違がっとるやないかいっ！
GDBスタブ側の割り込みハンドラから、ユーザープログラム側の割り込みハンドラへ飛んでくるときのユーザーベクタアドレスは、0x02000000じゃなくて、0x20000000ね。もう一度言う、にひゃくまんエイチじゃなくて、にせんまんエイチです！ったく、だからいつまで経ってもC級なんだよ！
もう面倒だから、スタブの方を改造してデバッグモニタ割り込みは全部スタブ側だけで処理するようにしてしまった。ユーザープログラム側に渡そうとして変な動きしてたからとりあえずはより安定して動くことを目標にした方がよさそう。
それから、GDBでシングルステップ実行ができない件。なんだよ、このスタブ、's'も'c'も同じ扱いじゃねーか！そりゃ's'したら走り続ける罠。ううぅぅ、オノレ、C級出版め。余計な面倒かけやがって。
途中で入手したCortex-M3のマニュアルを見て、サクッと's'コマンドに対応させてみる。う～ん、いい感じ、stepもできるようになったゾ。breakpointも張れるし、これで苦節半年、ようやく本来の目標に戻れる。と思いきや、正月休みも終わりタイムオーバー。
やっぱり今年も中途半端な一年に終わりそうな予感。。。
あっ、disassembleがうまく行かなかった件、これはもしかするとGDBがTバリアントを見てARMモードかthumbモードかを見て逆アセしてたからなのかなぁ。今はちゃんとdisassembleできてる。GDB6.8はthumb2で何とか使えそうではある。
それから疑問が１点残った。's'はソースレベルのstep実行、'si'がアセンブラレベルのstep実行だったような記憶があるのだが、なぜか's'でも'si'の動きをしている。GDBは's'でも'si'でも同じパケットをスタブに投げているようなので、どうもGDB自体がソースレベルでstep実行しようとはしていない模様。なんでだ？これも今後の課題だ。
とりあえず、breakpointを張って止める、変数のinspectionができる、これだけでも大進歩だ。あとは時間を確保すること・・・それが問題だな。
0 件のコメント:
コメントを投稿