ARM & Android ARM & Android デバッグの実験室より： Androidのデバッグ ハードウェア・デバッガに統合することで、複数の領域にまたがる見 です。 つけにくいバグを追跡、修正する必要があります。 デバッグとトレースの基本 このような「プラットフォーム支援の実行モード・デバッグ」だけで Hagen Patzke、Software Design Embedded Debugging、Lauterbach 社 A GNU デバッグ・サーバをプロセスに接続し、デバッグすれば良いの 済むのであれば、問題はありません。コーディングとデバッグを楽 ディング・ブロック」を掘り下げる前に、組み込みプラットフォーム、 しんでください！ つまり「ターゲット」上のデバッガの基本機能について、少し考えて みましょう。 Java のようにコンパイルされていない、しかし解釈済みの高級言語は、 デバッガとは、物理的なマシンの状態を示すスナップショットを、プ デバッグに仮想マシン（VM）インタプリタの助けが必要です。 ndroid は、開発とデバッグのための優れたサポートが提供されています。高級言語（Java™）アプリケー ションのデバッグは、Dalvik インタプリタのデバッグ・サポートで十分に対応されていますし、C/C++ で書 ログラマの意図を仮想的に表現した 1 つ以上の抽象化レベルにマッ シンを止めれば、外付けの Java/Dalvik デバッガとデバッグしている アプリケーションとの通信リンクが途切れてしまいます。外部のネ 分も、内蔵の GNU デバッグ・サーバで比較的容易にデバッグできます。新しいプラットフォームに移植したい場合 イティブ・コードをデバッグする場合も同じです。オペレーティン すべて完璧、記事はおしまい。本当にそうでしょうか？ ピングするものです（息を吸うのを忘れないように）。 このことは、Android についても言えます。したがって物理的なマ かれたシステム・サービスなど、それ自体のプロセスで実行されるプラットフォームの「ネイティブな」部 は、高機能なハードウェア支援デバッグ・ツールを使用し、低位のドライバとカーネル自体の初期デバッグを行います。 しかし、はっきり言って重要なのは、プログラム・カウンタの値 が 0x123456 であることではなく、それが MP3 プレーヤのソース・ コードの 14 行目にあることです。プロセッサの 3 番レジスタの値が グ・システム・カーネルを停止すれば、GNU デバッグ・サーバのプ 0x1003 であることではなく、それがアプリケーションのステート・ ロセスも停止します。あなたが、Android を新しいプラットフォーム マシンの「playback_active」を意味することが極めて重要となる場 に移植するシステム開発者だとしましょう。あるいは、ドライバ等の 合もあります。 低位のコンポーネントと GUI 等の高位のコンポーネントを緊密に接続 もし、あなたがシステム開発者で、前述の複数の領域にわたるバグを追跡しなければならないとしたら、ここからが する新しい低位のサービスを構築しているとしましょう。システム・ 現実の世界です。デバッグ支援を有効にしたとたん、姿を消してしまうバグを見つけなければならない場合もあるで コンポーネントを 1 つずつ別々にデバッグする間は、ほとんどうまく しょう。あるいは、プロダクション・ステージやセキュア・プラットフォームを手掛けていて、ソフトウェア支援デ デ バ ッ グ の さ ま ざ ま な「 ビ ル 一定の時間、プログラム実行を「トレース」し、例えば「プロファイ リング」によってアプリケーションのどこを実行するのに時間がか いきます。 かっているか、どんなバグが頻繁に起こっているかを調べることも有 効です。このために「プログラム・トレース」、「システム・トレー バッグが使えないかもしれません。このような場合、状況は非常に厳しくなります。 ス」を行うハードウェアとソフトウェアがあります。いくつかのプ ラットフォームでは、プログラム・カウンタの値（や分岐）だけでな この記事では、一般的な組み込みデバッグについて簡単に紹介し、さまざまな抽象化レベル、および Android デバッ く、データ・メモリの変更も一定時間トレースできます。仮想マシン グの特殊な点について説明します。 のプログラムは、仮想マシン（VM）インタプリタを実行する物理マ シン用の単なる普通のデータなので、VM を持っている場合は、デー タ・トレース機能が非常に便利です。 プラットフォーム Android がこれほどの成功を収めた理由は、 Android のデバッグ機能のすべて アプリケーション開 仮想マシン（VM）アプリケーションの「支援型」デバッグ おそらく上から下まで完全に統合されたプラットフォームだからで 発者は、非常に良い待遇を受けています。優れた SDK が提供され、ア しょう。きちんと動作し、使える機器を構築できるよう、何もかも綿 クティブなコミュニティがサポートを提供しているからです。また、 密に定められています。さらに、Google™ がエミュレータと実際の機 無償の Eclipse プラグインを使えば、自分の Java/Dalvik アプリケー しかし、ネットワーク・スタックのようなコア・コンポーネントを変 器の両方で「オープン・ソース」として公開したときは、ARM 実装が ションを開発できるだけでなく、Android デバッグ・ブリッジ（ADB） 更する必要がある場合を考えてみてください。低位のドライバでハー その機能を実世界に証明しました。 経由で Java ワイヤド・デバッグ・プロトコル（JWDP）の拡張バー ドウェア・ブレークポイントにヒットした瞬間、ホストとターゲット ジョンを使用し、Dalvik 仮想マシン（VM）と機器上のデバッグ・デー の間のすべてのネットワーク通信が切れ、ネットワーク・ベースのデ Android の中心は、専用に変更を加えた Linux 2.6 カーネルです。この モンの助けを借りることで、極めて効率的にデバッグを行うことがで バッグ支援は使えなくなってしまいます。フリーズした機器を接続し カーネルの機能は多数ありますが、特に重要なのは、サービスと仮想 きます。 て何が起こったかを調べたいなど、「事後」デバッグが必要な場合は どうでしょう。 マシン処理にマルチスレッディングを適用することです。Android の 「システム」は、ネイティブ・コードと仮想マシン・プログラムの両 「ネイティブ・コード」を書く、例えば、サービス・プロセスでアプ 方で構成されているからです。 リケーション・コードの重労働をするときも、同じことが言えます。 22 この場合、「ネイティブ・デバッグ」と「Java デバッグ」の両方を同じ 数字（コード）とアセンブリ言語（ニモニック）の抽象化レベル 23 ARM & Android ARM & Android 一言で言うと、「デバッガ」のコア・タスクとは、生のメモリとレジ あれ、ソフトウェアをビルドするには、「ターゲット」機器のアーキ 言で言えば、使用可能なプロセッサ・コア上にあるプログラム実行の スタ・データを、意味を成すものにマッピングすることです。一定 テクチャ向けに「クロスコンパイル」する必要があります。PC の「ホ 選択的な開始と停止、メモリ、コア、ペリフェラル・デバイス・レジ の時間にわたって（選択した）システム状態の変化を記録することは スト」とターゲット・アーキテクチャが同じでないこともあります。 スタの調査と操作、ブレークポイント（プログラムを所定のロケー そして、そのソフトウェアを組み込み機器にロードします。 ションで停止）のセットと削除です。 「トレース」と呼ばれ、性能のボトルネックを特定したり、断続的な バグを見つけたりするのに役立ちます。 これでやっとソフトウェアを起動し、デバッグすることができます。 カーネルのデバッグと OS 認識 他が万事 OK であれば、デバッグの対象はアプリケーションです。ア テム・カーネルの登場です。現代のプラットフォームは、マルチタス プリケーション・コードの実行を開始する前に何か問題が生じれば、 キングとマルチスレッディングをサポートしています。つまり、2 つ インフラを先にデバッグする必要があるでしょう。「プラットフォー 以上のプログラムやプロセスを同時に実行できます。これは、シング ム自体の上でデバッグする」という従来の PC の手法は、ここでは使え Linux のプロセス・ディスプレイ ル・プロセッサ・コアでも同じです。オペレーティング・システムは、 ません。 各プロセスに「タイム・スライス」を与え、次のプロセスに移ります。 組み込み分野で、ソフトウェアをロードし、デバッグする標準的な方 アプリケーションが 1 つだけなら簡単に見つけてデバッグできますが、 法は、ターゲットを JTAG（IEEE1149.1）などのハードウェア・インタ 今度は複数のアプリケーションが「同時に」動作しています。同じア フェースを介して、外付けのデバッグ・ハードウェアに接続すること プリケーションの複数のインスタンスが同時にアクティブで、そのう です。デバッグ・ハードウェアは、「ホスト」上で動作するグラフィ ち 1 つだけをデバッグしたいこともあるでしょう。 カル・ユーザ・インタフェース（GUI）で制御します。GUI 経由、また 混合アセンブリ言語と高級（C）言語の抽象化レベル オペレーティング・シス はスクリプト言語を使ってメモリ・コンテンツを変更し、ソフトウェ 前述のように、純粋な「ネイティブ・コード・デバッグ」では、オペ アをターゲット上に「ダウンロード」した後、システムとアプリケー レーティング・システムのブート・コード、デバイス・ドライバ、タ ションを実行、デバッグします。 スク・スケジューラのような低位の構造体の問題を、容易に見つける ことができます。 ネイティブ・コードのデバッグ VM アプリケーション名付きのプロセス・ディスプレイ 化レベルへのマッピングを見てみましょう。最低レベルは、オンチッ しかし、カレント・アプリケーション・プロセスがプログラム・メモ プ信号と電圧です。1 つ上のレベルは、レジスタとメモリのビットです。 リのどの部分を実行しているのか、インスタンス変数がどこにあるか もう 1 つ上は、数（10 進数または 16 進数で表現）です。次のレベルに、 （複数あるかもしれませんね）を知りたい場合は、デバッガがオペレー やっとアセンブリ言語命令が出てきます。ここで、支援なしのデバッ ティング・システムを知っている必要があります。すなわち「OS 認 グは終わりです。 識機能」を持つデバッガが必要なのです。 レームワークを実行しているマシンでソフトウェア・デバッガも実行 幸運なことに、現代的なコンパイラは「デバッグ情報」を出力し、ア 実は、この機能は、デバッガに簡単に付与できるものではありません。 し、ほとんどのアプリケーション・デバッグを行います。ほとんどの センブリのロケーションを高級言語（C/C++ など）のソース・コード プロセッサ・コアや高級言語コンパイラ（C/C++ など）と異なり、オ オペレーティング・システムと PC アーキテクチャ自体が、このタイ の行にマッピングします。他の「デバッグ・レコード」は、論理デー ペレーティング・システム（OS）自体が、ほとんどの PC に搭載され プの「ソフトウェア・ベースの」デバッグを積極的にサポートしてい タ型をメモリ内のデータ・レイアウトにマッピングします。この付加 ているような固定された「既製の」ものではないからです。組み込み ます。 的なデバッグ情報はプログラム・ファイルをかなり増大させますが、 分野の OS は、競争力のある新製品を作るために積極的に変更し、調 これなしでバグを探すのは「暗闇を手探りする」のと同じです。やは 整する必要があるものです。 ターゲットとホスト 高級（C）言語の抽象化レベル マシン・ステートの抽象 PC では、アプリケーションや開発フ 組み込みプラットフォームは違います。ほとんどのターゲット機器は、 り、カレント・プログラム・カウンタを高級言語のソース・ファイル 処理性能、メモリ、使用可能なインタフェースが限られています。し 内の行にマッピングする必要があるでしょう。そうすれば初めて、物 変更可能な OS は、デバッグにとって「動く標的」です。したがって、 たがって、開発やデバッグは通常、十分な性能を持った外付けの「ホ 理的なプロセッサ・コアおよび任意の抽象化レベル上で実行される 構成や調整によって、デバッガに自分の使っている OS バリアントに スト」マシンで行われます。 対する「OS 認識機能」を持たせる必要があります。 「ネイティブ・マシン」コード内で何が起こっているかを見ることが できます。 ここで、あなたの組み込み機器のインフラ（ブート・ローダ、ドライ バ、オペレーティング・システム）について考えてみましょう。何で Linux カーネルのタスク 24 このことは、組み込みリアルタイム・オペレーティング・システム ネイティブ・コード・デバッガでは、何ができるのでしょうか？ 一 （RTOS）が普及すると明らかとなり、ローターバッハ社はそのニー 25 ARM & Android ARM & Android ズに応えて、Extension Development Kit（EDK）を備えた「TRACE32 この場合は、「ストップモード」でデバッグします。仮想マシン内で、 サ ネ ッ ト・ イ ン タ フ ェ ー ス、 カ メ ラ、USB、UART、 他 多 数 の 開 発 Extension」メカニズムを実装しました。TRACE32 Extension を使えば、 現在どのプログラムが実行されているかを知り、変数とオブジェクト に有用なハードウェアが付属しています。JTAG デバッグ用の端子 既存の OS 認識機能（Linux 用など）に調整を加えたり、必要に応じて が何の値を持っているかを知るには、まず、実マシンのメモリ・コン も 含 ま れ ま す。 予 算 が さ ら に 限 ら れ て い る 場 合 は、BeagleBoard ユーザが自分で書いたりすることができます。 テンツを読み出す必要があります。次にデバッガが、VM 自体および キット（EBVbeagle など）の検討をお勧めします。これには、ARM® アプリケーションのオブジェクト・データのデータ構造を発見、分析、 Cortex™-A8 と DSP を含む TIOMAP 3530 が使用されています。デバッ 解釈し、システムとその状態の良好な「VM 抽象化レベル」表示を提 グ端子なし、イーサネットや LCD はボード自体に搭載、リビジョン 供せねばなりません。 によっては Android に調整を加える必要があるかもしれませんが、 仮想マシン ... プロセッサの性能は、どんどん高まりました。 これにより、ハードウェアすら抽象化することが可能となり、かつて コストは非常に少なくて済みます。 は大きなメインフレーム機のものだった仮想マシン（VM）が組み込 VM デバッグの問題の 1 つは、（オペレーティング・システム・カー み分野にも導入されました。 ネルと同様）どんな VM も「単なる 1 つのソフトウェア」であり、最 ネイティブのマシン・コードをプロセッサ上で直接実行するのではな 終製品のニーズに合わせて変更されるということです。VM コード く、仮想マシン（VM）でコードを実行する場合、別の「仮想」マシン とそのデータ構造に大きな変更があれば、デバッグ・ツールもそれ をエミュレートするソフトウェアを実行することになります。 に対応させねばなりません。さもなければ、解釈した情報は使えま Android デバッグ・セッションのサンプル 結論と展望 現在、提供されているのは、非常に初歩的な仮想 マシン（VM）デバッグ・サポートです。Android 上で Dalvik VM をデ バッグするには、Linux プロセスに関する知識が不可欠です。なぜな ら各 VM アプリケーションが、それ自体のプロセス内で動作するか せん。 らです。当社の Linux Awareness は、メモリ構造を解釈し、システ このような VM には、いくつかの利点があります。1 つは、VM 向けに ム・ホールト時に Linux カーネルが何をしていたかのアイデアを与 書いたコードを、VM の実装を持っている他のどんな実プロセッサ上 Android は、この好例です。アプリケーション開発者は Java でコー でも実行できることです。もう 1 つは、VM アーキテクチャを特定の ドを書きますが、そのクラス・ファイルから生成された Dalvik バイ ニーズ（スタック・ベース、レジスタ・ベースのマシン、セキュリ トコードが、標準的な Java™ VM で動作することは決してありません。 ティ向上など）に合わせて変更できることです。内部の VM 演算や命 したがって標準的な Java デバッグ・ツールは、何も有意義なものを表 令コードも必要に応じて最適化できます。言い遅れましたが、実は、 示できないことになります。 え、現在では Dalvik VM のアプリケーション名を抽出、表示すること もできます。ローターバッハでは、TRACE32 デバッグ・ツール製品 群に「VM 認識機能」を持たせるよう、現在、研究開発が進んでいま す。Android on ARM は、VM 認識機能を持つ初のプラットフォームと なるでしょう。数カ月内に、ネイティブ /VM デバッグ機能の量産も 新世代の実マシンとしてハードウェアに VM を構築することすら可能 期待されています。 プロセッサ自体について言えば、Dalvik VM の「プログラム・コード」 です。 は、単なるデータです。したがって、ネイティブ・コードに有効な ミニグロッサリ 皆さんはおそらく、既に日常的に VM を使っています。例えば多くの 「プログラム・トレース」は VM のトレースやプロファイリングに使え 携帯電話プロバイダは、SIM として JavaCard™ スマートカードを選択 ません。このタスクには、データ・トレース機能（または、非常に巧 しています。さまざまなベンダのさまざまなプロセッサやハードウェ 妙な工夫）が必要です。ターゲットから何の支援も得ずに VM デバッ アにスマートカード・ハードウェアを使用し、なおかつソフトウェ グ・サポートを提供することは、非常に困難です。ローターバッハで ア・アップデートを管理しやすいからです。また、解釈済みの Java は現在、支援なしの内蔵ネイティブ /VM デバッグについて研究中です。 バイトコードは、ネイティブのマシン・コードより本質的にセキュア ソリューションの一部は、VM の変更に応じてメーカが調整を加える ストップモード・デバッグ：すべてのオペ レーティング・システムとアプリケーション・プロセスを含むプラッ トフォームが「デバッグ・モード」で保留され、デバッガがチェック できるようすべての状態がフリーズします。通常、JTAG テスト・アク セス・ポートを使用して接続する外部デバッグ・ハードウェアが必要 です。 ことのできる「TRACE32 VM Awareness Extension」となる予定です。 です。 OS 認識メニューのある Android デバッグ・セッション ランモード・デバッグ：プラットフォームは、デバッグされていない これが、汎用的な VM サポートを可能にするでしょう。 オペレーティング・システムとすべてのタスクを実行します。この もちろん VM にも欠点はあります。1 つは速度です。VM 自体がソフト ... そして仮想マシンのデバッグ ウェア・プログラムとして、データ・ストリームを VM 命令として解 1 つ の 方 法 は、 仮 想 マ モードは通常、オペレーティング・システムへの変更、あるいは少な ボード 当社のパートナーである韓国の MDS Technology 社は、 釈する必要があります。これは、ネイティブのマシン・コードをプ シン（VM）自体に直接デバッグ・サポートを追加することです。そ ロセッサ・コア上で直接実行するよりも低速で、VM の実装が「適切」 うすれば、専用の「デバッグ・インタプリタ」などがデバッグ要求を MEP-6410（M6R2）ARM11™ リファレンス・ボードを Android オペレー でなければ、セキュリティ上の問題が生じる恐れもあります。 処理できます。Android は、そのような実装の例であり、通常、純粋 ティング・システム・ポート付きで提供してくれました。 くともプラットフォーム上でのヘルパ・アプリケーション（いわゆる 「デバッグ・サーバ」）の実行を必要とします。Android には、ホスト への接続を管理する Android デバッグ・ブリッジ・デーモン（adbd）、 内蔵の Dalvik VM デバッグ・サポート、ネイティブ・プロセス用の な Java™ アプリケーションのデバッグについては有効です。しかし、 我が社にとって幸運なことに、人間は必ずバグを入れてしまうもので 「VM デバッグ・インタプリタ」がアクティブなときにはバグが姿を見 MEP-6410（ M6R2 ）の中心は、Samsung S3C6410 SoC に組み込まれ GNU デバッグ・サーバ（gdbserver）など、いくつかのデバッグ・ヘ あり、それは VM コードについても言えます。ですから、仮想マシン せず、これを使えない場合はどうしましょう？あるいは、VM と Linux た高性能な ARM1176JZFS™ です。この ARM11 リファレンス・ボー ルパがあります。 （VM）のデバッグに対するニーズがあり、デバッグ上の利点と問題点 カーネルの相互作用をデバッグしなければならない場合は、どうで ドは、3.5 インチ（240x320）の LCD を装備し、Android に最適化した しょう？ タッチ・スクリーン、128MB の NAND FLASH、128MB の RAM、イー があります。 26 END 27
© Copyright 2026 Paperzz
