デバッガ周り
昨日書こうとして，睡魔に負けてしまったネタ．
ことの起こりは，一昨日のコメント．
実は，何を修正すればよいか，どれくらいの修正になるかは，頂いたコメントを読んだ3秒後には見積もれていた．
でも，安直に直して副作用があると嫌なので，じっくり考えてみた．デバッガを使う作業(デバッグ)は，タダでさえ憂鬱な作業である．デバッガがワケの解らん挙動を示すほどエンジニアの苦痛になることはないので*1．
まず，直さない理由．
「ROMに書いても問題が無い」
コメントにあったとおり，”cannot access memory”と出る可能性はある．これはある意味当然で，書こうとして書けない(ROMだから)といっているだけ．
ロードの時間は確かにかかるかもしれないが，remapしてRAMに書いても同じだけの時間がかかる．つまり，ROMだけの問題ではなく，早晩不満が出てくるし，そのときは，ユーザインタフェースではなくより下回りのデバッガやJTAGで解決すべき問題となる．ユーザインタフェースで解決するのはスジがよろしくないかもしれない．
「CDTとあまり乖離させたくない」
開発者の事情? ユーザ無視? いやEclipseの派生品である以上，これは結構深刻．
実際，具体例もある．KMC製のEclipseプラグイン．CDTとあまり乖離させない設計だったのに，CDTのデバッガインタフェースに関する無神経な仕様変更*2により，CDT3.x系との共存はできなくなっている．最近のプラグインは3.xベースのものが多く，KMC製のEclipseは実質"使えない"ものとなってしまっている．不幸な話だ．
今はタイミング的には微妙な時期で，早晩CDT4.0が出てくる．現在のCDT3.1.2にも部分的に4.0の足音が聞こえるコードが入っているが，これが結構大きな変更になるっぽい．…が，多分に付け焼き刃的な部分も多く*3，もう一回劇的な修正が入る可能性がある．どこでPizzaFactory3が追随し，どこまで独自系を貫くか，タイミング的に微妙である．ひじょーに微妙である．
一方，直す理由．
「修正は非常に軽微である」
通常のJavaインデントで10行程度の追加をすれば実現可能と見積もられる．テストや公開手続の時間を含めても4時間もあれば終わる仕事である．
「他のデバッガにもついている」
いたずらな機能競争は好まないが，基本的な機能は押さえておくべきのような気もする．この機能は基本的な部類に入るだろう．
決定的に直す理由
客先に向かう電車の中でこの辺りまで考えて，正直なところ「直さなくても良いか」と思えてきていた．
しかし，客先から帰る電車の中で直さなきゃいけない決定的な理由が思い浮かんだ．
それは，binutilsのバグっぽい挙動，だ．
この挙動については id:monamour555:20070214 の「GNU ldのマッピング」にさらっと書いた．
実はあのバグは机上の議論で見つかったものではない．
TOPPERS/HRPカーネルをYDC製MicroVIEWでデバッグしようとしたときに直面した，激痛を伴うバッドノウハウだったりする．
今回の件に併せた場合の最悪のシナリオはこんな感じ．
- PizzaFactory3を購入し，期待に胸を膨らませている開発者A君．ちょっと凝ったバイナリをRAMにロードさせてみた．
- GNU ldのお茶目な挙動でプログラムヘッダが重複し，RAM上に期待通りに展開されなかった．
- A君は，「しょーがねーなー」とか言いながら，手作業でRAMを書き換えた．
- デバッグが一巡終えたA君，GDBを再起動した．せっかく手作業で入れた内容は，またもや上書きされた．
- ツールベンダに問い合わせたら，仕様です．とあっさり切り返された*4．
- A君，うーわんこんなツール使えねーよ，と巨大掲示板にかきまくりたくなった．
…
うーむ．
ツールベンダの対応の悪さに業を煮やした結果がPizzaFactory3なのに，ミイラ取りがミイラになるところだった．がっでむ．
GDBはセクションヘッダがあればプログラムヘッダに優先して使っていたような記憶(曖昧)があるので，もしかすると問題にはならないかもしれないのだけれど，libbfdがあまりにもアレなので，回避方法を用意しておくのは重要．とっても重要．
そんなわけで
近日中に「バイナリをロードしない」という機能追加があると思われます．
