デバッガサポート再考．
「最後はGDBで幸せになろう」とか言ってみたい．
それにしては.gdbinit関連のサポートが甘いという点が結構気になる．むちゃくちゃ気になる．
方針検討中
で，どうするか．Zylin CDTのように，テキストボックスを与えて「好き勝手書いてね」というのが最も安直な解．
しかしデッドコピーはしたくないしなぁ．それが圧倒的に使いやすいものならパクるインスパイアの余地はあるけれど，あまりにも安直だもんなぁ，アレ．
ターゲットが判っているなら，Javaコードに埋め込むとか，拡張ポイントに記述できるようにするとか．…頭でっかちすぎるなぁ．Eclipseを知らない組込みエンジニアにとって使いやすいとは到底思えん．
たぶん．決定．
プロジェクト中にgdbinitを置くということを，スタイルとして提案しちゃうというのもあり得る．
うーん．これが割といいかなぁ．現状のデバッガフレームワークでは，起動構成と対応するプロジェクトは事実上1対1*1の関係だし．
プロジェクト中にファイルを置けるとなると，CDTのILanguageサポートが使えるので，アウトラインなどを使った編集支援もできるのよね．
関数定義なんて始めると，カラーハイライトも欲しくなるし．うむうむ．
加筆
コメントについて加筆です．シミュレータとエミュレータでは起動構成が別であると割り切れば問題はないはずです*2． GDB内蔵シミュレータの殆どはペリフェラルに関して独自で，数あるボードバリエーションの一つと看做すほうが自然です．ボードが違えば，gdbinitも替えるのが自然です．
GDB内蔵でも，実機さながらの結構力が入ったペリフェラルエミュレーションをしているものも例外的に*3ありますが，ペリフェラルエミュレーションを有効にするためにはtargetコマンドにいろいろオプションを付ける必要があるので，gdbinitを修正しなければなりません．
世の中にはGDBスタブ機能を持ち実機と遜色のないターゲットシミュレータも存在します*4が，その場合は，gdbinitの内容も一切変える必要がないはずですので，とっかえ引っ替えを気にする必要が無いということになります．JTAG-gdbのproxyがmonitorコマンドを独自に持っていたりして，必ずしも「はず」が普遍的に当てはまるわけでも無いのではありますけれども…．
いずれにしても，「環境が違うなら起動構成を替えてください」のワンフレーズで統一的に運用可能だと思います．
