ICEによるデバッグは生産性が低い

と思うのですが,マチガイですか。機能と質に拠るのでしょうかね。

例えば,VisualStudio(VS)並に統合された環境なら,悪くないです。しかし世の中にはVSのマルチスレッドデバッグ対応機能などを知らない人がいます。というか組み込み系では知らない人が多数派の恐れがあります。

ある業界での常識は別の業界では非常識です。JavaでAnt関連使わないなんて,原始人扱いされることがあるようですが,C/C++ではCVSは「ロックできないので非常識」と言われます。そのわりにVSSVSと統合して使うとバグに出くわすことはあまり周知されていないようです。

EclipseCDTの存在を知らなくたって生きていけますし,Cygwinでクロス開発する人が,なぜCDT on Eclipseを使わないかの理由は,「重い」「不安定」ではなく,「知らない・興味が無い」「なんでそんなもの必要なの?」です。

15年以上前のPC向けの統合開発環境黎明期と似たレスポンスのような気がします。TC?どうしてコマンドラインで使わないの?VZ?EDLINで充分じゃん。若い人は贅沢だね・・・

好むと好まざるに関わらず,主流は必ず統合環境へシフトしていきます。ただ問題は市場規模があまりにも小さいのとツールがカネを生まないでしょうから,VSのような完成された環境は期待できないでしょう。ある一団はいつまでたってもショボイツールでシコシコ非生産的な作業に従事することは間違いないです。

実行環境のリソースがリッチになればなるほど,低レベルの開発環境について興味を持つ人は減っていきます。例えば,ミドルウェアの類はまさにそこを突いて営業活動をしてくるのでしょう。

WindowsLinuxならば,デバイスドライバのデバッグや,カーネルのデバッグといったレベルの話です。

しかしちょっとした装置では,それはCPUのコンフィグレーションレジスタの設定ミスとか,CPLD上のアドレスデコーダのバグの抽出などといったばかげたレベルの話なのです。あるいは仮想メモリの無い環境ならば,「自分が担当してない全然無関係のモジュールが書き込んだポインタのアドレスがおかしい」というだけの原因を突き止めるのに,ICEでステップ実行ですか。

何が言いたいかというと,どうにも同じ言葉が全然違う意味で使われることが問題の一端のようです。あるいは文脈がまやかしというべきか。

ICEの生産性が低いと言った場合,追跡すべき事柄は上記のようなしょうもない原因であることが多いわけです。けして,256個のスレッドやプロセスの複雑に入り組んだバグの追跡ではないのです。つまり,それをもって「ICEじゃなきゃ原因追求できないだろ?」というのはちとおかしい。しかも世にあるICEは万能でもVSよりも高機能でもないのです。256個のスレッドの入り乱れは,所詮ちまちまソースレベルのデバッグではどうにもならないです。

結局,複雑な仕組みはデバッグしやすい簡単な構造で検証してから徐々に肉付けしていく形でしか実現できないことは,プロなら分かっているでしょう?いきなりトンデモな構造を設計するバカがいて,これまたバカ正直に実装して,そんなものブートしたっていきなり動くわけないわけですから。そこには必ず非常に地道な作業があるわけです。

ミドルウェアやOSのポーティング請負は,とにかくそこまではやってくれるのでしょうから,投げれる場合は投げてしまえばよいと思うのです。そうなれば,アプリ開発の現場なのに,最後はICEの台数と経験者数次第とか,意味不明な連中を駆逐できることでしょう。もちろん,そっちの中の人は大変でしょうけどね。まともなRTOSメーカは昔からBSPなどといったパッケージでハードウェアメーカと連携しています。そういうMS-intel連合的なことに頭が回らないのは相当困った人が雲の上にいるんです。

ポーティングさせたって,ロクに動かないことはあるでしょうがね。それはしょぼい所に投げちゃったのが運の尽きでしょう。

で,そういうような話をしたいのに,「ROMエミュレータJTAGデバッガかで話がだいぶ違うよね」などというわけのわからん反応に悩まされるわけです。まるで「常駐プログラム書くならMS-Cじゃないとね」「DPMIはBorland製のものが好きだナァ」などという話を聞いているような錯覚を覚えます。

もうどうでもいいです。どうせ知ったかぶりで書いている妄想ですしね。