「あなたは満足？今のデバッグ方法」 セッション：S2-4-3 コーディネータ: 武井 千春（横河ディジタルコンピュータ） 参加者10名程度 ----------------------------------------------------------------------- [自己紹介] ICEの提供を生業としている 昔は8bitマイコンを扱っていた 「みんなお菓子を食べて話そう」と言ってヨーロッパ土産のお酒入りのチョコ レートを頂いた。(おいしい) ----------------------------------------------------------------------- [議論のとっかかりとして、デバッグの現状を紹介] 仕様決定からデバッグ、評価までのサイクルをどんなやり方でするべきか？ 最近、したいことと出来ることが食い違っているのでは？ 特にデバッグではできることの範囲が狭まってきている。 その理由として、プロセッサの複雑化によってICEに使うエバチップが作りに くくなっていることが挙げられる。 それに対して開発者からは、 ・いろいろできなくても、シンプルにデバッグできればいいんだ ・開発人数の増加によりツールをいくつも買わなくてはならないので安いツー ルでいい(高価なモノをいくつも買ってられない) ・そもそもデバッガはいらない ・JTAG ICEがあればいい (JTAGとは：MPUの内部にあるデバッグ機能を備えたチップ、最低限度の機能の み持たせて、それを使ってデバッグをする) ・プログラムをいちいち自分で作るから駄目なんだ、ちゃんと再利用できるよ うに作るべきだ！ ・マイコンには最低限のデバッグ機能を入れる→大きい機能は求められてない という声が増えている。 でも本当にそうなの？ 例えばトレース機能がない場合を考える： 某osのようにブルースクリーン時にレジスタダンプだけ見せられても… →問題の場所だけでなく問題が起きる前に何が行われていたかの情報が重要である （特にマルチタスクマルチスレッドの場合データ流をあらかじめ決定できない） →トレース情報を得ることは大事だ！ 性能が上がれば盛り込みたい機能も増えてしまって、結局常にいたちごっこになる。 どうやったらシステムの性能を確保できるのか評価できるのか？ ・評価ツールは最後だけ使うんだからひとつだけでいいんでは？という声がある しかし評価を最後しか行わなければ、 最後の評価時に実行スピードが間に合わないことが発覚→どのモジュールも遅 い→力仕事で間に合わせる という事態が起こり得る。 これは機能仕様を書いたとき性能使用も決めるべきで、モジュール単位で性能 仕様を満たしているかをチェックするべきだ。 ・実機での確認は不要では？ せっかく抽象度を上げているのにc/c++で追いかけるのはイヤだ。 もっと上のレベルで追いかけたい。 計画との乖離を考える。 実際にどのくらい工程に時間がかかったかを見ると、 ・仕様検討段階で計画との乖離があることはあまり無い。 ・外部設計でも期間が2倍3倍になるなんてことはない。 ・デバッグ段階では原因が見つからなければどんどん時間がかかる。 →計画の後期に行けばだんだん予定との乖離が大きくなる Aさん：それは前半工程のおろそかな部分のしわ寄せが後半工程に来ているのでは？ デバッグの段階の仕様レベルのバグは仕様レベルで何とかすべきなのでそれは 仕様検討工程の計画の乖離に含めるべきでは？ Bさん：仕様検討のところでほんとに検討しているのか？仕様がそれでいいの かの評価は？ 武井さん：そういうこともある、一個一個の工程でしっかり作っていくというのも 大事なポイントだが、作業単位で考えて、やはり後半工程の予定のブレは大きい という声も結構上がっている。 ・デバッグ手法 デバッグ手法は若者にちゃんと伝わっているのか？ 優秀な人間は自分で解決するかもしれないが、そうでない人はどうする？ 資料が無いのでは？ 組み込み分野はただでさえ資料が少ないのだ 効率的なデバッグについての資料はどれだけあるのか？ 教えられるエンジニアはいるのか？ 上の世代の人自身も教えられたわけではない→どう教えればいいの？？ 体系立てた標準的な取り組みが無いことが問題だ ・デバッガで出来て欲しいこととはなんだろう？ 実行過程、変数アクセス、全てトレースしたい タスク遷移を教科書のように見てみたい システムコールトレースもパラメータごと見たい どこが性能ボトルネックか教えてほしい(v-tuneはいい線いってる) 実機確認も上流ツールレベルで行いたい ----------------------------------------------------------------------- [議論] [高機能なツールをみんなが使わなくてもという声が増えてきているがそうなのか？] Aさん：携帯の開発者に大きいICEを渡しても使えるのか？現状では使わなくなっ ている Bさん：デバッグとテストの境界が会社によって違う。デバッグツールより、 テストツールが不足していると聞く。 しょうがないのでデバッグツールでテストしている 武井さん：境界は結構ぶれるところがある、 どこで分けようか？ ・バグを追っているのか？仕様を満たしているのか？でわけるのか ・道具によるのか？何がデバッガ？ 武井さん：みなさんどうですか？ Aさん：デバッガを使ってテストはすると思うが？テスターはイメージできない ツールが生成したテストプログラムを実機で動かすときデバッガを使うのでは？ Dさん：（テスト中）ちゃんと動いているときはデバッガはいらない、 問題発生時にはじめてデバッガが必要になる。 武井さん：リアルタイム環境で同じことを再評価しようとすると再現が難しい ？？(聴き取れませんでした) 最後の最後のモノに近い人とソフトウェアの論理を考える人がきっちり 繋がっていないと思う [テストとデバッグの違いは？] テストとはなにか？モジュールが要求を満たしているかを検証するものか？ デバッグとはなにか？ 武井さん：テストが全て網羅できていればデバッグは不要ではと思う Eさん：要求を満たすかの検出がテスト、あまり派手なツールはいらないのでは？ 問題の原因を調べるのがデバッグ。 トレースをもっと簡単に低負荷でできるようになれるといいな Bさん：昔トレース機能自体のバグで死に掛けたことが… 武井さん：マルチタスクでの開発で、システムが動くとなにかおかしい →デバッガで状態を見てみると常にアイドル状態になっていた。ということがあった。 osは大丈夫と保障して、その上でデバッグ、としていればやりやすい。 特定のポイントだけ抽出する道具があれば皆に使われるだろう。 Eさん：機能の事を言い出すときりが無い、多機能だとかえって使い勝手が悪くなる Bさん：osを見ているのかプログラムを見てるのかわからなくなる、自作部分だけを 見られるようにしたい 武井さん：osの内部を見せられても…とは確かに思う。 多機能になると使うのが大変になるだろうと思う。 では、最低限の機能という線引きはどこだろう？ osとアプリを分ける機能は欲しい チームだと自作部分と他人の作成部分も分けたい 信用できる人の部分は隠蔽して疑わしい部分を分ける道具だてがあるといい。 [性能に関する問題は起きませんか？] 性能評価ツールとはなに？ 武井さん：指定した関数の測定してくれるとか、統計的にしかとれないが、平均 消費時間の最短最長を表示する。 システム全体である関数がどれだけ時間を使っているかを教える。 仕様どおりの処理時間がまず守られてないといけないが、モジュール単体ではなく、 システム全体で関数の消費時間の合計値をみて改善していくことが必要 Dさん：ハードリアルタイムではもっと細かいレベルでの分析が必要だ。 そのためにPC上でプロファイルを取る。 武井さん：プロファイルをとろうとするとどうしてもオーバーヘッドが馬鹿に ならないときがある Dさん：あまり細かくプロファイルしようとするとプロセッサ内部のパイプラインが 崩れるので実行速度が極端に遅くなって困ることがある 武井さん：タスク単位でプロファイルが取れると遅いタスクをほかに分担させる ことができるかも Dさん：キューに入っている待ちタスクを確認できれば対策できそう 武井さん：osがそういう機能を持っていると思う。 osに性能評価の道具が入っているといいかも どういう条件のときキューが多くなるか等を教えてくれるという機能がある といいかも A：itron仕様に一応あるはず Bさん：nexcessのHさんは割込みによる評価をしている、 そういう機能はまだまだこれからだろう。 どのOSを採用するべきかという質問がよくあるが、性能はどう測るのが妥当なのか？ →結局機能で選んでる。 相手よりも自分のほうがいいと示してもらわないと選べない Aさん:モノによって強みが違っているので、一般に比較できる形での公開は難しい Bさん:そもそも各CPUへOSを移植する水準が違う、cpuのHW的な機能、性能に 依るところもあるので難しい 武井さん：デバッグって、若手に伝わっているのか？ 一人がカバーできていたころはその人は相当の理解をして物を作れたが、 今は数十人で作るためそうはいかない…その状況でどう評価するのか？ 武井さん：昔はHWがどう動いているのかイメージできていたが最近はHWの複雑化のため 難しい、専門の人しかわからなくなっている。 どうすればより効果的な評価、デバッグ法が伝わっていくのだろう？ Bさん：製造メーカがソフトを作っていたときはよかったがソフト子会社をつ くるようになると、そこには実機が無い。だから子会社では実機テストがで きる環境が無い、若手の中には実機テストを経験してない人もいる。その結 果、自分は何を制御しているのかがわからなくなっている。 武井さん：しかし100万ステップのプログラムを書いている人がその動作の全てを イメージできているわけではない。 Bさん：ほんとはosが線引きをして、アプリケーション開発者に負担をかけないよ うにしなければならないが組み込みでは難しい。 武井さん：どうやって若い世代に伝えるか？モノ(実機)のそばで伝えなくては 力が弱まるのでは？HWの動きをイメージできる人がいた時代に比べると能力が 弱まる傾向にあるのでは？ 今のやり方がうまく進むトレーニングの仕方は？ Bさん：NEXCESS上級ではデバッグも課題になっていた、Hさんも若い人だし ----------------------------------------------------------------------- [まとめ] 武井さん：ボリュームが増えて新しい人が増えているが、組込み開発は どうやっていけばいいのか？ 若い世代、数も増えている今、何を、どう伝えていけばいいのか？ こういうネタをかかえながら次の機会でも話し合いできればいいですね。 Bさん：(大きい声では言えないが)swestの参加者の中にデバッグしている 人が少ないように思う。小さい会社だと全部自分でやっているんだけど…