-------------------------------------------------------------------------------- セッションS2-4-3 「あなたは満足？今のデバッグ方法」 コーディネータ: 武井 千春（横河ディジタルコンピュータ） 参加者8名 -------------------------------------------------------------------------------- ○コーディネータの自己紹介 武井 以前は8080，Z80の開発をした 現在も開発環境に近い仕事をしている ○資料の説明 ・現状 プロセッサの動作速度が向上してきている カーナビは800MHｚとか1Gが要求されている 半導体メーカの声では，「最近では，デバッグ環境でこれをやってほしいという声を聞かない」 安いツールでないと数が集まらない．安いのが当たり前 ・このセッションのテーマ デバッグ環境で，本当にしたいことはなにか どうしたら良いデバッグ，評価ができるのか ・JTAG-ICEの説明 コアのそばにデバッグ機能をもったユニットがあり，JTAGという端子をもつ 基本機能として，レジスタの内容を表示するなど・・・ 拡張機能として，以下のようなものがある． 特定アドレスがアクセスされたら，止めずにその情報を出力 トレースをとって，その情報を出力（JTAG端子にそれようの端子を追加） 関数の処理時間を測定する 半導体メーカにとっては，コア以外にもデバッグ機能ユニットの検証が必要となる． デバッグユニットが本当に必要なのか？ どのような機能が必要なのか？ 検証のコストに影響する．いらないなら機能をつけないほうがよい． 問題を発生した部分が，そもそもバグの被害者ということもある． 早く問題を発見する際には，問題の直前に何が実行されていたのかを知るのが非常に重要！ デバッグ機能の一つにOCD（On Chip Debug）トレースがある マイコンの中のロジックからトレースすることができる ・盛り込みたい機能 リアルタイムシステムでは性能の確保，リアルタイム性の保証が仕様である． どうやったらシステムの性能を確保できるか？その性能を評価するのか？ 性能評価ツールは最後だけ使うから？ どの処理も全部少しずつ遅い． →機能仕様を書いたときに，性能仕様も決めておく必要 ・計画と実施の乖離はどこか？ コーディングで，3倍という食い違いは少ないが，2倍はありうる． 仕様検討は，完了したという検証方法がないので，時間がきたら次に行ってしまう． 参加者：その結果，実装やデバッグで仕様を修正することがあるので，仕様検討の乖離も大きいと思う． 仕様の検証手法が欲しいよね． 組込みのデバッグ手法全般について議論したい 若い世代にデバッグ技術が伝わっているのか不安． 資料や教科書がない．個別に学習をしている印象がある． 教育が体系化されていない． 教えられるエンジニアがいない． 出来てほしいことの例として以下が挙げられる 実行経過や変数アクセスをトレースでみたい 実行すると関数ごとプロセスごとに実行時間を得たい 性能のボトルネックを教えてくれる Intel V-Tuneは大分高機能でよい -------------------------------------------------------------------------------- 議論開始 -------------------------------------------------------------------------------- 現在の環境で満足か？ 現状で十分という声をよく聞く． A：全員が高級者に乗れるわけではないので，軽で満足するしかない B：あるなら高級車に乗りたい どっち？ 高級な機能をもった機器があっても使いこなせるのか？ デバッグツールの存在自体を知らない人もいる． デバッグとテストの違いが会社ごとにあいまい． デバッグツールとテストツールの使い分けが間違っていることもある テストを考えて仕様を決めるべきだと思う． バグをおってるのか，仕様を満たすことを検証するのか． テストをするときにもデバッガは必要だろう． 単体テスト用スクリプトを自動生成しても，最終的にはデバッグツールを用いてテストをすることになる． テストの条件は，最終まで継続して持ち込みたい． テストとデバッグの違いってなにか？ テストはあるモジュールが要求された結果を出しているかどうかを検証するもの． デバッグはある課程に問題があれば，その問題の原因を追って解決すること． 問題の検出がテストだと考えている． その解決，対策手法がデバッグ． ツールはトレースを軽い動作でやってくれるツールが欲しい． トレース機能自身もバグをもつことがある． 信用できないのでテストプログラムは自分で作ることにしている． 通信系でマルチタスクはデバッグがたいへん． ある時点でブレークしてもアイドル状態だったことが多い． 原因がどこかわからない． トレースの機能は必要だ． OSの機能を疑う状態になると非常に大変になる． 通信系は，問題の原因が遠い過去に発生することがあるので，長いスパンでトレースして記録するツールがあると良い． あらゆる機能をもつツールは，逆に使い方が分かりにくくなることがある． OS内部を知らないと，OSの中をみてるのか，アプリケーションを見てるのかが分けられない． OSとそのほか（タスク）で分けて表示するツールがほしい． ツールに求める最低条件とは何か？ チーム開発で，自分と他人のコードを分けて表示すること． 信用できる部分と，信用できない部分を分ける． 信用できる部分は見たくないから． 性能評価ツールとは具体的に何？ 指定した関数の実行時間を測定する（ばらつきも含めて）． システムの処理時間の中で各機能の処理時間を個別に測定してくれると嬉しい． 個別の処理時間の合計値があると，ボトルネックを特定できるかも知れない・ ハードリアルタイムだともっと細かく解析する必要がある． タスクの処理に関しては予め，数学的解析が必要だと思う． マルチタスク環境で，タスク分割と振り分け，動作状況の良し悪しを判断するツールがあるとよい． 今は経験と勘に頼るしかない状況だから． OSの内部状態（タスクキュー）を表示する機能． そのため，OS内部に状態表示用の機能を盛り込む必要がある． OSのデバッグ機能としてはITRONのデバッグ仕様がある． しかし，性能の評価的なインタフェースはない． ブレークしてイベントフラグを立てたり，タスクの状態をかえる機能が欲しい． TOPPERSもやってない． 結局，現状ではOSを選ぶ基準は，提供される機能になっている． 性能評価のためのOSの機能がほしい． そうしないと，選ぶ基準がない． セールストークで，評価の一部を売りとして公開しているところがある． OS間の評価は，例えばTOPPERSの場合，移植水準がことなるので，単純にはできない． マイコンごとにも機能か異なるし，最適化するかどうか，チューニングのレベルに依存する． タスク分割の方法を仕様と比較して，満たしているかどうかを教えてくれる機能がほしい． OSメーカ同士で性能を比較する手法，または機能があるとうれしい． 開発規模が増加している（一人で担当するのではなく，数十人でやる）とデバッグ手法が複雑になる． 専門が特化して，範囲が狭くなると，システム全体のデバッグ手法はどうするか？ 実機を意識せずに組込みソフトを作っている会社もある． 物に触れる機会が少なくなっている． 実際にシステムを想像しにくくなっている． 本当はOSが境界線を設けてアプリ開発するべきだ． しかし，組込みOS上のアプリ開発ではOS内部の知識が必須である． 最近ではやっと組込みでもシステマティックな開発手法が導入されてきた． 国も力を入れ始めている． 実機に触れながら開発しないと，実際の問題を解決できないと思う． 開発者の力が弱くなっているのか！？ 規模が増大して，アプリに新しい人間が沢山流れ込んでいるのが現状． 今後は，組込み開発者の数は増えるが，質が問題となる． 教育はどうすれば良いのか・・・． 現状では綺麗な解が見当たらないが，普段から問題意識を持ち続けて，開発する． また別の機会で，議論をしていきたいと思う． ありがとうございました