• 検索結果がありません。

この手の問題を診断する際に Simics は完璧なツールなのですが 実行するためには 問題が発生するプログラムを Simics に取り込まなければなりません すなわち Simics 上で Simics を実行するのです まず Simics 内部に開発ホストの複製を作成します これは何も難しいことでは

N/A
N/A
Protected

Academic year: 2021

シェア "この手の問題を診断する際に Simics は完璧なツールなのですが 実行するためには 問題が発生するプログラムを Simics に取り込まなければなりません すなわち Simics 上で Simics を実行するのです まず Simics 内部に開発ホストの複製を作成します これは何も難しいことでは"

Copied!
8
0
0

読み込み中.... (全文を見る)

全文

(1)

Simics 上での Simics のデバッグ

投稿者:Jakob Engblom,, 2012/12/05 私はたびたび書いたり話したりしていますが、Simics は並列処理のバグのデバッグと、マルチスレッド やマルチコアシステムの障害に対するデバッグには実に有効です。非常に複雑なアプリケーション、具 体的に言えば Simics 自体の上で、このことを証明した例を最近経験しました。この例は、Simics の反復の完 成度と、複雑なソフトウェアに潜む手ごわいバグを解決する際の有効性の両方の、分かりやすい証明であると 考えています。 私はたびたび書いたり話したりしていますが、Simics は並列処理のバグのデバッグと、マルチスレッドやマ ルチコアシステムの障害に対するデバッグには実に有効です。非常に複雑なアプリケーション、具体的に言え ば Simics 自体の上で、このことを証明した例を最近経験しました。この例は、Simics の反復の完成度と、複 雑なソフトウェアに潜む手ごわいバグを解決する際の有効性の両方の、分かりやすい証明であると考えていま す。 この例の説明は、Simics に含まれていたバグから始めましょう。ある特定の構成に限って発生するバグがあ りました。Simics のターゲットは、プロセッサのシミュレーションをテストする、ベアメタル型テストコー ドを実行する Power アーキテクチャマシンです。この構成ではたまに、Simics またはモデルに含まれている バグのために Simics がクラッシュしました。テストを 50 回実行するうちの 1 回程度しか発生しないので、追 跡が難しいバグでした。診断のためにデバッガを接続してバグの再現を試みると、そういうときに限って発生 しません(昔からハイセンバグと呼ばれるものです)。

(2)

この手の問題を診断する際に Simics は完璧なツールなのですが、実行するためには、問題が発生するプログ ラムを Simics に取り込まなければなりません。すなわち、Simics 上で Simics を実行するのです。まず、 Simics 内部に開発ホストの複製を作成します。これは何も難しいことではなく、単純に 8 コア Intel ターゲッ ト上に標準的な Linux の Fedora 16 をインストールするだけです。 Linux をインストールしてブートすると、 システムのチェックポイントが取得されます。

次に、ホストからの開発コードツリーが TAR ファイルとしてパッケージングされて、DVD イメージファイル に置かれます。Simics は、ブートされたターゲットシステムのチェックポイントから起動され、Simics 上で 稼働している Fedora Linux は、DVD イメージを仮想 DVD ドライブに挿入してマウントします。TAR ファイ ルは、ターゲット上のファイルシステムにコピーされて展開されます。このようにして、Simics のインスト ールが完了すると新しいチェックポイントが取得されて、Simics 上で Simics を実行できるようになります。 この時点で得られる成果は、完全に自身で完結していて、制御可能で、再現可能な環境です。

以下のスクリーンショットは、Simics 上で Simics が稼働する様子を示しています。ホストと外部の Simics Fedora システムの両方で、同じデスクトップの壁紙を使っています。

(3)

次のステップは、Simics の中にあるバグの再現です。この目的のために、バグに遭遇するまで内部の Simics を繰り返し実行するシェルコマンドを使用します(このセッションは明らかに、Simics をインストールした 後のチェックポイントから開始します)。

(4)

ここまでの流れをまとめると、Simics 上で稼働する Simics を構築しました。Power アーキテクチャ構成の 「内部 Simics」はホスト上でクラッシュしました。Fedora 16 が稼働している「外部 Simics」は、開発ホス トの仮想レプリカ(ただし Simics 内部を除く)を提供しています。

(5)

 その Simics スクリプトで、IA ターゲットシステムに含まれているプロセッサに 割り当てたタイムスライスを変更しました。こうすることで、並列実行プロセス と、Simics でシミュレートしている Fedora 16 OS 内のスレッドのスケジューリ ングに大きな変化が起こり、バグを早く再現する(バグを再現するまでの内部 Simics の実行回数が少なくなる)ことにつながります。  内部 Simics が起動されて、タイミングの変更が IA プロセッサに適用されたら、 内部 Simics がテストケースの実行を開始する前にチェックポイントを取得しま す。これで、バグに直接つながるチェックポイントが利用できます。バグの再現 のためにターゲットのウォームアップや、Simics を特定の構成にする必要は全 くありません。チェックポイントは結果的に、この問題に関する自己完結したバ グレポートとなります。  内部 Simics の segfault(セグメントエラー)ハンドラにマジック命令(ブルー スター)を埋め込みます。これで、内部 Simics のクラッシュは簡単に捕捉でき ます。正しいページフォルトの捕捉を試みたり、正しい場所にブレークポイント を設定するよりも、このようにマジック命令を使用する方が簡単な場合がありま す。マジック命令とは、コード中でバイオマーカーのような役割を果たすもので、 デバッグ情報や OS Awareness に関係なく常にトリガーの働きをします。しか も、マジック命令は起動するまでオーバーヘッドは発生しません。

(6)

ついに、内部 Simics を 20 回程度実行すると、バグをトリガーできるようになりました。チェックポイントと Simics の反復能力によって、バグの再現は困難ではなくなりました。Simics のクラッシュは、もはやいつで も再現できるようになったので、次はデバッグに移って、Simics がクラッシュする理由を考えることにしま しょう。たまにしか起こらないハイセンバグは、100%再現可能なボーアバグに変わりました。

デバッグの最初のステップは、内部 Simics の中に多数ある、動的にロードされたモジュールのマッピングに ついて考えることです。これは、外部 Simics を稼働させて Fedora シェルに Ctrl-Z を送信し、内部 Simics を 一時停止させることで実現します。このとき、Simics 上で動作している Fedora Linux 上の/proc ファイルシス テムに、ロードアドレスを検出するための応答指令信号が送られます。Simics が起動した後にチェックポイ ントが取得されているので、これはチェックポイント中で検出される、ソフトウェア構成内のマッピングであ ることが分かります。チェックポイントがオープンされるたびに、同じマッピングが適用されます。こうして 情報が保存され、使用している Simics モジュールのためのシンボリックデバッグ情報を設定するために利用 されます。 デバッグの次のステップでは、チェックポイントを再びオープンし、そこからリバース実行を始めて、マジッ ク命令がヒットするまで実行を続けます。ここで、segfault ハンドラが実行される前に内部 Simics が動作し ていた最終時点のバックアップを取得するために、OS awareness が利用されます。これによって外部 Simics は、内部 Simics のクラッシュを引き起こした命令とまったく同じ命令を実行します。

Simics は、コードが存在しないロケーション(BCDE)でコードの実行を試みていたことが判明しました。

そこから 1 命令戻ると、BCDE ロケーションへの JMP 命令を実行していました。

では、この JMP BCDE 命令を実行するに至った理由は何でしょう。この命令は明らかに、Simics の静的コー ドには含まれていませんが、Simics 自身が命令実行中に何か生成したと考えられます(Simics には JIT コン パイラが含まれているので、実行中にコードを変更する可能性は、十分にあります)。

(7)

誤った JMP 命令が作成された状況を調べるために、命令(JMP BCDE)にメモリー書き込みブレークポイン トを設定して、リバース実行を進めてみました。Simics は、命令の「JMP」部分をメモリーに書き込んだ時 点で停止しました。ここでスタックのバックトレースを実行して、コードは JIT が生成したコードストリーム に 5 バイトの「JMP XYZQ」命令を書き込もうとしていたことが分かりました。JMP 命令コードを含むバイ トの書き込み時にブレークポイントがヒットしたことから、命令が実行されて Simics がクラッシュしたとき、 命令以外の 4 バイト(JMP 命令が本来目指していたロケーションである XYZQ)はまだ書き込まれていなか ったことが分かります。 命令を(プロセッサ上で)書かれている順序どおりに 1 ステップずつ実行することで、内部 Simics の中でス レッドの切り替えが起こり、入ってきたスレッドが即座に 5 バイトの JMP 命令を実行して現在の問題が起こ ったと判明しました。JMP バイトだけが書き込まれていたことから、狙っていた XYZQ(もともとの ABDCE コードを実行するにはそれでもよかった)へのジャンプではなく、BCDE へのジャンプとなってしまったこと が分かります。したがって、今回の状況は、読み取りはメモリーの内容をコードに書かれたとおりに実行して、 書き込みは通常のデータの書き込みを行うという性質に基づいた、読み取りと書き込みの競合条件の問題であ ると診断されました。問題が特定されれば、その修正はとてもたやすいことでした。 同じ構成で Simics の競合条件がもう 1 つ見つかり、それも修正されました。さらに頻度の高いケースである 複数のスレッドの同時実行に関係する問題で、共有しているデータ構造の更新および読み取りを実行する間に 同期が不完全になるというものでした。

(8)

要約すると、このブログエントリーでは、Simics を利用して、現実世界に存在する複雑なソフトウェアシス テムの 1 つでもある Simics の、並列実行のバグを検出して修正した一例を説明しました。成功のカギとなっ たのは、Simics が備えている反復能力です。タイミングが関係する、たまにしか発生しないイベントにも対 応できますし、チェックポイント、スクリプティング、リバース実行、デバッグ設備と連携させることもでき ます。 原文はこちら:http://blogs.windriver.com/m2m/2012/12/biggest-predictions-for-m2m.html 本社ブログサイト:http://blogs.windriver.com/

参照

関連したドキュメント

これはつまり十進法ではなく、一進法を用いて自然数を表記するということである。とは いえ数が大きくなると見にくくなるので、.. 0, 1,

次に、第 2 部は、スキーマ療法による認知の修正を目指したプログラムとな

点から見たときに、 債務者に、 複数債権者の有する債権額を考慮することなく弁済することを可能にしているものとしては、

はい、あります。 ほとんど (ESL 以外) の授業は、カナダ人の生徒と一緒に受けることになりま

・カメラには、日付 / 時刻などの設定を保持するためのリチ ウム充電池が内蔵されています。カメラにバッテリーを入

世の中のすべての親の一番の願いは、子 どもが健やかに成長することだと思いま

戦略的パートナーシップは、 Cardano のブロックチェーンテクノロジーを DISH のテレコムサービスに 導入することを目的としています。これにより、

従って、こ こでは「嬉 しい」と「 楽しい」の 間にも差が あると考え られる。こ のような差 は語を区別 するために 決しておざ