スマートフォン
タブレット
Android
デバッグ

JTAG によるインテル® Atom™ プロセッサー・ベースの Android* OS のデバッグ

同カテゴリーの次の記事

Android* OS 上でのリモート・アプリケーション・デバッグ

この記事は、インテル® デベロッパー・ゾーンに掲載されている「Debugging Android* OS running on Intel® Atom™ Processor via JTAG」の日本語参考訳です。

システム・インテグレーターとデバイスメーカーにとっては、デバイスドライバーやシステム・ソフトウェア・スタック上でもアプリケーションが同じように動作することが重要です。例えば、追加のプラットフォームに特定の周辺機器のサポートを実装する必要がある場合や、新しいインテル® Atom™ プロセッサー・ベースのデバイスにオペレーティング・システムを移植する場合には特に重要になります。

この後のセクションでは、IEEE 標準 1149.1 (JTAG) ベースのデバッグ・ソリューションについて説明します。また、ARM* アーキテクチャーとインテル® アーキテクチャーの違いがシステムレベルのデバッグに与える影響についても言及します。

1.1. JTAG デバッグ

組込みインテリジェント・システムの分野では、ファームウェア、OS レベルのシステム、デバイスドライバーのデバッグに、JTAG インターフェイスを使用するのが最も一般的です。JTAG (Joint Test Action Group) IEEE 標準 1149.1 は、「プリント回路基板のテストに使用されるテスト・アクセス・ポート用の標準テスト・アクセス・ポートおよびバウンダリースキャン・アーキテクチャー」を定義しています。この標準規格は一般に、JTAG デバッグ・インターフェイスと呼ばれています。当初から、回路基板テスト用の標準規格として、OS に依存しない OS システムレベルのプラットフォーム・デバッグ用の標準インターフェイスとなるように開発されました。

JTAG の詳細情報と最新のシステム・ソフトウェア・スタックのデバッグにおける使用法は、Randy Johnson と Stewart Christie による「JTAG 101; IEEE 1149.x and Software Debug」 (英語) を参照してください。

OEM およびパートナーのアプリケーション/ドライバー開発者から見た場合、システムオンチップ (SoC) 統合インテリジェント・システムやスマートフォン・フォーム・ファクター・デバイスのさまざまな部分で実行するドライバー/ソフトウェア・スタック・コンポーネント間の相互作用を理解することは、プラットフォームの安定性を向上させる上で非常に重要です。シリコンの評価者から見た場合、低レベルのソフトウェア・スタックにより、プラットフォームが実際の利用状況で露呈するさまざまなストレス要素を示すテスト環境が提供されます。つまり、最近の SoC では、個々のハードウェア・コンポーネントのユニットテストにパスするだけでなく、パッケージ全体および複雑な実際の相互作用を理解する必要があります。このレベルの洞察を得るには、JTAG の詳細なハードウェア認識機能とターゲット上で実行している Android* OS のステート情報をエクスポートする機能を組み合わせた、JTAG ベースのシステム・ソフトウェア・デバッグ・アプローチを利用します。

特にデバイスドライバーのデバッグでは、チップセットの周辺機器の正確な状態と、デバイスドライバーと OS レイヤーおよび残りのソフトウェア・スタックとの相互作用の両方を理解することが重要です。

システムデバッグの観点から Android* を見た場合、デバイスドライバーと OS カーネルは Linux* の特別なブランチにすぎません。実際、2.6.3x 以降の Linux* のように扱うことが可能です。

インテル® Atom™ プロセッサー Z2460 は、IEEE-1149.1 および IEEE-1149.7 (JTAG) のバウンダリースキャンと MPI PTI (Parallel Trace Interface) に加えて、インテルの JTAG 準拠拡張デバッグポート (XDP) により BTS (Branch Trace Storage)、LBR (Last Branch Record)、AET (Architectural Event Trace) ベースの命令トレースをサポートしています。

さまざまな JTAG ベンダーから Android* に対応したシステム・デバッグ・ソリューションが提供されています。
• Wind River (http://www.windriver.com/products/JTAG-debugging/)
• Lauterbach (http://www.lauterbach.com)
• インテル (http://software.intel.com – アクセス制限あり)

1.2. Android* OS のデバッグ

Android* ベースのプラットフォームのデバッグが複雑なのは、電力消費を抑えるために Android* が低電力のアイドルステートとスリープステートを積極的に利用することが原因です。このため、低電力ステートでのデバッグが課題となります。

• 一部の低電力ステートで JTAG 機能を維持します。
• 維持できない場合、JTAG のチップセットのパワードメインが再度有効になったとき直ちに JTAG を再アタッチします。

これらのプラットフォームにおける多くの OS レベルの問題は、消費電力モードの変更とスリープ/ウェイクアップ・シーケンスに集中する傾向があります。

エージェント・ベースのデバッグでも、JTAG デバイス・インターフェイスを使用する場合でも、システムデバッガーは、OS 開発の主要な目的達成を支援する便利なツールです。

デバッガーは、ブートプロセスの検証と、ランタイムエラー、セグメンテーション・フォルト、ブート中に正しく開始しないサービスなどの安定性問題の解析と修正に使用できます。

ページテーブル、ディスクリプター・テーブル、命令トレースの詳細なアクセス情報を提供することにより、OS の構成に関する問題の特定と修正にも使用できます。命令トレースとメモリー・テーブル・アクセスの組み合わせは、スタック・オーバーフロー、メモリーリーク、データアボートなどの根本的な原因を特定できる非常に強力なツールとなります。

図 1 は、物理アドレスから仮想メモリーアドレスへのページテーブルの変換を示しています。変換テーブルの深さとアドレスされるメモリーブロックの粒度を定義する際に x86 で利用可能な、高い柔軟性を備えて、容易にアクセスでき、可視性のあるメモリーレイアウトであることが、OS レベルでのシステム開発ではさらに重要になります。

図 1: 論理アドレスからリニアアドレスへの変換

論理アドレスをリニアアドレスに変換するため、プロセッサーは次の処理を行います。

  1. セグメントセレクターのオフセットを使用して、GDT または LDT のセグメントのセグメント・ディスクリプターを特定して読み込みます。(このステップは新しいセグメントセレクターがセグメントレジスターにロードされた場合にのみ必要です。)
  2. セグメントがアクセス可能であり、オフセットがセグメントの範囲内であることを保証するため、セグメント・ディスクリプターのアクセス権とセグメントの範囲を確認します。
  3. セグメント・ディスクリプターからセグメントのベースアドレスをオフセットに追加してリニアアドレスを形成します。
  4. ページングが使用されない場合、プロセッサーはリニアアドレスを物理アドレスに直接マップします (つまり、リニアアドレスがプロセッサーのアドレスバスの外に出ます)。リニアアドレス空間がページングされると、セカンドレベルのアドレス変換が使用され、リニアアドレスが物理アドレスに変換されます。

プロテクトモードで動作する場合、インテル® アーキテクチャーでは、リニアアドレス空間を大きな物理メモリー (例えば、4GB RAM) に直接、または小さな物理メモリーとディスクストレージに (ページングを使用して) 間接的にマップすることができます。リニアアドレス空間をマップする後者の手法は、仮想メモリーやデマンドページ仮想メモリーと呼ばれます。
ページングが使用されると、プロセッサーはリニアアドレス空間を物理メモリーまたはディスクストレージにマップ可能な固定サイズのページ (通常は 4KB) に分割します。プログラム (またはタスク) がメモリーの論理アドレスを参照している場合、プロセッサーはアドレスをリニアアドレスに変換してから、ページングメカニズムを使用してリニアアドレスを対応する物理アドレスに変換します。リニアアドレスを含むページが現在物理メモリー内にない場合、プロセッサーはページフォルト例外 (#PF) を生成します。ページフォルト例外の例外ハンドラーは、(プロセスで物理メモリーからディスクに異なるページを書き込んで) ディスクストレージから物理メモリーにページをロードするようにオペレーティング・システムに指示します。ページが物理メモリーにロードされると、例外ハンドラーからのリターンにより例外を生成した命令が再開されます。リニアアドレスを物理アドレス空間にマップし、(必要なときに) ページフォルト例外を生成するのにプロセッサーが使用する情報は、メモリーに格納されたページ・ディレクトリーとページテーブルに含まれています。
ページングは固定サイズのページを使用する点でセグメントとは異なります。通常、保持するコードやデータ構造と同じサイズである (つまりコードやデータの大きさで変化する) セグメントと異なり、ページのサイズは固定です。セグメンテーションが使用されるアドレス変換の唯一の形式であれば、物理メモリーのデータ構造のすべての部分がメモリーに含まれます。ページングが使用された場合、データ構造の一部がメモリーに含まれ、別の一部がディスクストレージに含まれます。
アドレス変換に必要なバスサイクルの数を最小限にするため、最も新しくアクセスされたページ・ディレクトリー・エントリーとページ・テーブル・エントリーが、プロセッサーのトランスレーション・ルックアサイド・バッファー (TLB) と呼ばれる領域にキャッシュされます。TLB は、バスサイクルを要求することなく、現在のページ・ディレクトリーとページテーブルの読み込みのほとんどを行うことができます。TLB にページ・テーブル・エントリーが含まれない場合に限り (ページが長い間アクセスされていないときに発生しやすい)、追加バスサイクルが発生します。

この点は、インテル® アーキテクチャーとほかのアーキテクチャーで Android* OS ソフトウェア・スタックを開発および構成する際の 2 つの重要な違いです。LDT (ローカル・ディスクリプター・テーブル) と GDT (グローバル・ディスクリプター・テーブル) を組み合わせた、セレクターベースのオフセット・アドレッシング・モデルは、可変のアドレスチャンクの粒度を使用して、物理メモリーから仮想メモリーにマルチレイヤーのアドレス変換を行うことができます。これは、保護され分離された複数のメモリー空間を含む分割された環境でカスタムメモリー構成を行う強力な機能ですが、正しく使用されないとメモリーアクセスの回数が増えます。このため、メモリーページ変換の優れた可視性が望まれます。

インテル® アーキテクチャーとほかのアーキテクチャーのもう 1 つの違いは、システム割り込みの制御です。例えば、ARM* では、ハードウェア割り込みの事前定義セットが 0x0 から 0x20 までの予約されたアドレス空間に含まれます。その後、これらの空間には割り込みハンドラーへのジャンプ命令が含まれます。インテル® アーキテクチャーでは、専用のハードウェア割り込みコントローラーが採用されています。ハードウェア割り込みはメモリー空間から直接アクセスされず、インテル® 8529 割り込みコントローラーによってアクセスされます。このアプローチの利点は、接続されているデバイスの I/O 割り込みの直接制御を割り込みハンドラーが考慮していることです。専用の割り込みコントローラーを使用しないアーキテクチャーでは、通常、IRQ 割り込みでより複雑な割り込みハンドラールーチンを処理します。

2.1. デバイスドライバーのデバッグ

OS レベルのデバッグ向けの優れた JTAG デバッガー・ソリューションは、カーネルでエクスポートされるほかの情報とともに、カーネルスレッドとアクティブなカーネルモジュールの可視性を提供すべきです。動的にロードされるサービスとデバイスドライバーのデバッグを可能にするには、ドライバーの初期化と破棄のメモリー位置をエクスポートするカーネルパッチまたはカーネルモジュールを使用します。

特にシステム構成とデバイスドライバーのデバッグでは、デバイス構成レジスターに直接アクセスしてその内容を確認できることも重要です。これらのレジスターと内容は、レジスターに格納されている 16 進数でリストされるか、図 2 に示されているようにビットフィールドとして視覚化されます。ビット単位の仮想化を行うと、関連するデバイスドライバーが対話している間、デバッグ中のデバイスステートに対する変更をより簡単にキャッチして理解できます。

図 2: デバイスレジスターのビットフィールド表示

start_kernel に到達するまでにデバッガーの実行コントロールをリリースすることで、Android* の圧縮した zImage カーネルイメージがメモリーに展開された後でコードを解析することができます。これは、カーネルシンボル情報を含む vmlinux ファイルがロードされたことを意味します。この時点で、ソフトウェア・ブレークポイントを使用できます。ブートプロセスのこの時点までは、デバッガーが初期化されていないメモリーにブレークポイント命令を書き込むことを回避するため、ブレークポイント・レジスター・ベースのハードウェア・ブレークポイントのみ使用できます。その後、アイドルループ mwait_idle に到達すると、オペレーティング・システムは正常にブートされます。

デバッグ・ソリューションで LBR (Last Branch Record) ベースの命令トレースへのアクセスが提供される場合、JTAG デバッガーの通常の実行制御機能とともにこの機能を使用して、例外での実行を停止し、実行フローを解析してランタイム問題の根本的な原因を探ることができます。

LBR は、ターゲットリセットからのコード実行をトレースするのに使用できます。コード実行の中断はこれらの MSR (Machine Status Register) に格納されるため、デバッガーは ‘To’ および ‘From’ アドレスを読み取って実行されたコードを再構築し、特定のメモリー範囲にアクセスして、コードを逆アセンブルすることができます。逆アセンブリーは、デバッガー・インターフェイスのトレース GUI に通常表示されます。割り込みにブレークポイントをセットすると、SMI (System Management Interrupt) やほかの例外の前に実行されたコードを調べるときに役立ちます。

2.2. ハードウェア・ブレークポイント

ARM* アーキテクチャーと同じように、インテル® アーキテクチャー・ベースのプロセッサーは、データやコードのソフトウェア・ブレークポイントとハードウェア・ブレークポイントのブレークポイント命令をサポートしています。ARM* アーキテクチャーでは、ブレークポイントとデータ・ブレークポイント (ウォッチポイント) に専用のレジスターが用意されています。一般的な実装では、2 つのレジスターを使用する傾向があります。これらのレジスターに値が含まれる場合、プロセッサーはプログラム・カウンター・レジスターまたはメモリー読み取り/書き込みによってセットされるメモリーアドレスに対するアクセスをチェックします。アクセスが行われると、実行が停止されます。これは、ブレークポイント命令で実行が停止されるという点でソフトウェア・ブレークポイントとは異なります。ブレークポイント命令は指定されたメモリーアドレスのアセンブリー命令を置換するため、ブレークポイント位置の命令が実行される前に実行が停止されます。

インテル® アーキテクチャーでのハードウェア・ブレークポイントの実装は ARM* での実装に非常に似ていますが、より柔軟です。

インテル® Atom™ プロセッサーのコアには、アドレスを格納する 4 つの DR レジスターがあり、メモリーフェッチの前に (場合によっては後に) メモリーバスのフェッチされたアドレスと比較されます。

これらの 4 つのレジスターをすべて使用して 、 以下のデバッグ実行制御イベントのトリガーとなるアドレスを提供できます。

  • 00 – 命令実行でブレーク
  • 01 – データ書き込みでのみブレーク
  • 10 – 未定義あるいは (アーキテクチャーが許可している場合) I/O 読み取りまたは書き込みでブレーク
  • 11 – (命令フェッチでない) データ読み取りまたは書き込みでブレーク

つまり、4 つのハードウェア・ブレークポイントはすべて、ブレークポイントまたはウォッチポイントのいずれかに使用できます。ウォッチポイントは、書き込み専用または読み取り専用 (あるいは I/O) ウォッチポイントのいずれかです。

2.3. クロスデバッグ: インテル® Atom™ プロセッサーと ARM* アーキテクチャー

インテル® Atom™ プロセッサーをターゲットとする多くの開発者は、固定命令長の RISC アーキテクチャーにおける開発経験があることでしょう。MIPS と ARM* は固定長の ISA (Instruction Set Architecture) の代表的な例です。一般に、インテル® Atom™ プロセッサーと ARM* アーキテクチャー・プロセッサー間のクロスデバッグ使用モデルは非常に似ています。概念的なデバッグ手法と問題の多くは同じです。

ただし、選択する組込みオペレーティング・システムが Linux* や Windows* のような標準オペレーティング・システムの派生バージョンである場合、インテル® Atom™ プロセッサーをターゲットとするインテル® アーキテクチャー・ベースの開発ホスト上での開発には、2 つの大きな利点があります。最初の利点は、インテル® アーキテクチャー上のソフトウェア開発市場向けに提供されているパフォーマンス、省電力解析、デバッグツールなどの豊富なエコシステムを利用できることです。2 つ目の利点は、アプリケーションの機能的な正当性とマルチスレッドの動作のデバッグをローカルに行えることです。この利点については後で説明します。

インテル® Atom™ プロセッサーと ARM* プロセッサーには、開発者が知っておくべきいくつかの相違点があります。これらの相違点は、次の 2 つのサブセクションで説明します。

2.4. 可変長命令

IA-32 およびインテル® 64 命令セットには可変長命令が含まれています。デバッガーは、固定 32 ビット間隔でコードを検査できないため、これらの命令のコンテキストに基づいてアプリケーションの機械語命令を解釈して逆アセンブルしなければいけません。次の命令の位置は、前の命令の位置、サイズ、デコーディングに依存します。対照的に、ARM* アーキテクチャーでは、デバッガーは ARM* モードから Thumb モードまたは拡張 Thumb モード (または逆) に切り替えるコードシーケンスをモニターするだけでかまいません。特定のモードでは、すべての命令とメモリーアドレスのサイズは 16 ビットまたは 32 ビットのいずれかになります。特定のデバイスレジスターへの呼び出しを正確にアラインする必要がある (デバッガーのメモリーウィンドウの出力を利用する) ファームウェアやデバイスドライバーの開発者は、可変長命令の潜在的な影響を理解しておくべきでしょう。

2.5. ハードウェア割り込み

システムコードをデバッグするときに重要となるアーキテクチャー上のもう 1 つの相違点は、ハードウェア割り込みの制御方法です。

  • 0 リセット
  • 1 アボート
  • 2 データアボート
  • 3 プリフェッチ・アボート
  • 4 未定義命令
  • 5 割り込み (IRQ)
  • 6 高速割り込み (FIRQ)

ARM* アーキテクチャーでは、例外ベクトルはアドレス 0x0 からアドレス 0x20 にマップされます。このメモリー領域は保護され、通常は再マップできません。一般に、0x0 から 0x20 のベクトル位置には、実際の例外ハンドラーコードが存在するメモリーアドレスへのジャンプが含まれます。0x0 のベクトルのリセットは、ファームウェアまたはプラットフォームのブートコードの位置へのジャンプです。このアプローチは、ARM* アーキテクチャーではハードウェア割り込みと OS シグナルハンドラー実装の柔軟性が低くなりますが、より標準化されます。0x0 から 0x20 のベクトル位置にハードウェア・ブレークポイントをセットすることで、デバッガーの割り込みを簡単にトラップできます。

インテル® アーキテクチャーでは、専用のハードウェア割り込みコントローラーが採用されています。

  • 0 システムタイマー
  • 1 キーボード
  • 2 カスケード方式セカンド割り込みコントローラー
  • 3 COM2 – シリアル・インターフェイス
  • 4 COM1 – シリアル・インターフェイス
  • 5 LPT – パラレル・インターフェイス
  • 6 フロッピー・ディスク・コントローラー
  • 7 利用可能
  • 8 CMOS リアルタイム・クロック
  • 9 サウンドカード
  • 10 ネットワーク・アダプター
  • 11 利用可能
  • 12 利用可能
  • 13 数値プロセッサー
  • 14 IDE — ハードディスク・インターフェイス
  • 15 IDE — ハードディスク・インターフェイス

割り込みはプロセッサーのメモリーアドレス空間から直接アクセスできませんが、インテル® 8259 割り込みコントローラーにアクセスすることで制御できます。割り込みのリストから分かるように、コントローラーは接続されたデバイスのハードウェア I/O 割り込みの直接制御 (ARM* プラットフォームの IRQ 割り込みや高速割り込みでの制御) をすでに考慮しています。この機能により、インテル® アーキテクチャーではオペレーティング・システム・レベルでの適切な割り込み制御を簡単に実装できます (特にデバイス I/O)。データアボートやセグメンテーション・フォルトのようなソフトウェア例外のマッピングは、インテル® アーキテクチャーでも柔軟に行うことができ、割り込みディスクリプター・テーブル (IDT) でアドレスされる割り込みコントローラー・ポートに対応します。IDT からハードウェア割り込みへのマッピングはソフトウェア・スタックで定義できます。ソフトウェア・スタックに依存しないデバッグ情報からこれらの例外を簡単にトラップすることはできません。インテル® アーキテクチャーのハードウェア割り込みをトリガーするソフトウェア・イベントをトラップするには、OS レイヤーの知識が必要です。これらの例外の OS シグナルを割り込みコントローラーにマップする方法を知る必要があります。一般に、システムレベルのデバッガーでも、ハードウェア・レベルで直接例外をトラップする代わりに、オペレーティング・システムからメモリーをマップしたシグナルテーブルで例外をトラップします。

2.6. シングルステップ

ARM* アーキテクチャーには明示的なシングルステップ命令はありません。インテル® アーキテクチャーでは、アセンブリー・レベルのシングルステップは、シングルステップ命令によりデバッガーに直接実装されます。ARM* では、シングルステップ命令は “run until break (ブレークまで実行)” コマンドとして実装されます。デバッガーは、すべての可能なコードパス (特に分岐命令以降のステップ) がカバーされていることを保証するコード検査を行うために必要です。デバッガーの実装という点から見た場合、”run until break (ブレークまで実行)” コマンドを実装することで高水準言語のステップが頻繁に必要になるため、多少の (過度ではない) オーバーヘッドが発生します。ステップの動作が多少異なるため、ソフトウェア開発者はこの違いに注意すべきです。

2.7. 仮想メモリーマッピング

仮想メモリーマッピング用のディスクリプター・テーブルとページ変換の実装は、少なくとも概念的には非常に似ています。インテル® アーキテクチャーでは、グローバル・ディスクリプター・テーブル (GDT) とローカル・ディスクリプター・テーブル (LDT) による入れ子の粒度調整が可能なメモリーページが仮想アドレス空間にマップされます。図 3 は、インテル® アーキテクチャーのリニアアドレスから物理アドレスへの変換を示しています。

図 3: インテル® アーキテクチャーのページ変換

ARM* では、ファーストレベルとセカンドレベルのページテーブルはより直接的に定義され、最大でも仮想メモリーの 1 レベルまたは 2 レベル深いページになります。図 4 は、ARM* のリニアアドレスから物理アドレスへの変換を示しています。

図 4: ARM* のページ変換

インテル® アーキテクチャーは、ディスクリプター・テーブル、パージテーブル、リアルモードの 32 ビット・アドレス空間、セレクターの base:offset モデルに依存するプロテクトモードの 64 ビット・アドレッシングに、さまざまなレベルの粒度を用意しています。ARM* は、各種モードで base:offset を使用しません。インテル® アーキテクチャーでは、ページテーブル検索が暗黙でより深くなります。ARM* では、定義されるセットは 2 つのページテーブルです。インテル® アーキテクチャーでは、ディスクリプター・テーブルが実際に入れ子のテーブルをマスクするため、実行するページテーブルの実際の深さはすぐに ARM* の深さの 2 倍から 3 倍になります。

アプリケーション実行に保護されたブロックとして特定のメモリーチャンクを割り当てるために OS レイヤーに使用されるシステム・メモリー・レイアウトとメカニズムに対して、インテル® アーキテクチャーのページ変換メカニズムはより高い柔軟性を提供します。しかし、開発者には、メモリー仮想化について理解し、メモリーリークやメモリーアクセス違反 (セグメンテーション・フォルト) を回避するという課題が与えられます。多くのメモリーを備えたフル機能の OS では、この問題を考慮する必要はほとんどありません。メモリー処理の可視性に優れたリアルタイム・オペレーティング・システムでは、この問題が露呈しがちです。

3. インテル® ハイパースレッディング・テクノロジーに関する注意事項

デバッグの観点から見た場合、物理プロセッサー・コアとインテル® ハイパースレッディング・テクノロジーで有効にされた論理プロセッサー・コアとの間に違いはありません。ハイパースレッディングの有効化は、BIOS のプラットフォーム初期化プロセスの一部として行います。このため、アプリケーションから見た場合、物理プロセッサー・コアと追加の論理プロセッサー・コアとの間で顕著な違いはありません。このテクノロジーにより複数のスレッドの並行実行が可能になるため、デバッグの課題は物理的なマルチコアをデバッグする場合と同じです。

4. SoC とヘテロジニアス・マルチコアの相互作用

SoC で多数のソフトウェア・コンポーネントとハードウェア・コンポーネントが相互に作用する場合、デバッグ中の問題の原因は増加します。異なるソフトウェア・コンポーネント間の相互作用は、多くの場合タイミング・センシティブです。コンポーネント間で多くの相互作用があるコードベースをデバッグする際、1 つの特定のコンポーネントをシングルステップで処理することは、現実的ではありません。デバッグそのものによりタイミング動作に影響を及ぼし、さらに悪い問題 (ハイゼンバグ) を引き起こす可能性があるため、従来の printf デバッグもこのコンテキストでは有効ではありません。

4.1. イベントトレースのデバッグ

この問題への対応を支援する、さまざまなスタティック・ソフトウェア・インストルメンテーション・ベースのデータ・イベント・トレース技術があります。共通なのは、少量の DRAM バッファーメモリーを利用してイベントデータをキャプチャーし、ロギング・メカニズムを使用してトレース結果をログファイルに書き込む点です。データ・トレース・モニタリングは、トレースロギング API を直接処理することでリアルタイムに、またはより複雑なソフトウェア・スタック・コンポーネントの相互作用を解析するトレースビューアーによりオフラインで行うことができます。

この種の実装では、SVEN、LTTng*、F-Trace* の 3 つが最も一般的です。

次の表は、Linux* オペレーティング・システム向けの (つまり Android* でも利用可能な) 3 つの実装の比較です。

図 5: データ・イベント・トレース・ソリューションの違い

詳細は、各製品の Web サイトを参照してください。

5. 参考文献

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

関連記事