RealView Compilation Tools ® バージョン 3.0 リンカ / ユーティリティガイド Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ RealView Compilation Tools リンカ / ユーティリティガイド Copyright © 2002-2006 ARM Limited. All rights reserved. リリース情報 本書には以下の変更が追加されています。 変更履歴 日付 発行 機密保持ステータス 変更 2002 年 8 月 A 非機密扱い 第 1.2 版 2003 年 1 月 B 非機密扱い 第 2.0 版 2003 年 9 月 C 非機密扱い RVDS v2.0 リリース(第 2.0.1 版) 2004 年 1 月 D 非機密扱い RVDS v2.1 リリース(第 2.1 版) 2004 年 12 月 E 非機密扱い RVDS v2.2 リリース(第 2.2 版) 2005 年 5 月 F 非機密扱い RVDS v2.2 SP1 リリース(第 2.2 版) 2006 年 3 月 G 非機密扱い RVDS v3.0 リリース(第 3.0 版) 著作権 ® または ™ のマークが付いた言葉およびロゴは、ARM Limited が所有する登録商標または商標で す。本書に記載されている他の製品名は、各社の所有する商標です。 本書に記載されている情報の全部または一部、ならびに本書で紹介する製品は、著作権所有者の 文書による事前の許可を得ない限り、転用・複製することを禁じます。 本書に記載されている製品は、今後も継続的に開発・改良の対象となります。本書に含まれる製 品およびその利用方法についての情報は、ARM が利用者の利益のために提供するものです。した がって当社では、製品の市販性または利用の適切性を含め、暗示的・明示的に関係なく一切の責 任を負いません。 本書は、本製品の利用者をサポートすることだけを目的としています。本書に記載されている情 報の使用、情報の誤りまたは省略、あるいは本製品の誤使用によって発生したいかなる損失・損 傷についても、ARM Limited は一切責任を負いません。 機密保持ステータス 本書は非機密扱いであり、本書を使用、複製、および開示する権利は、ARM および ARM が本書 を提供した当事者との間で締結した契約の条項に基づいたライセンスの制限により異なります。 製品ステータス 本書の情報は最終版であり、開発済み製品に対応しています。 Web アドレス http://www.arm.com ii Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 目次 RealView Compilation Tools リンカ / ユーティリ ティガイド 序章 本書について ................................................................................................. vi フィードバック .............................................................................................. ix 第1章 はじめに 1.1 1.2 第2章 リンカのコマンド構文 2.1 2.2 第3章 armlink について ......................................................................................... 2-2 armlink のコマンド構文 ............................................................................ 2-10 基本リンカ機能の使用 3.1 3.2 3.3 3.4 3.5 3.6 ARM DUI 0206GJ RVCT について ........................................................................................... 1-2 リンカおよびユーティリティについて ....................................................... 1-3 イメージ構造の指定 .................................................................................... 3-2 セクションの配置 ....................................................................................... 3-8 最適化と修正 ............................................................................................ 3-11 コマンドラインオプションを使用した単純イメージの作成 .................... 3-28 コマンドラインオプションを使用した C++ 例外の処理 .......................... 3-34 イメージに関する情報の取得 ................................................................... 3-35 Copyright © 2002-2006 ARM Limited. All rights reserved. iii 目次 第4章 イメージのシンボルへのアクセス 4.1 4.2 4.3 4.4 4.5 4.6 第5章 スキャッタローディング記述ファイルの使用 5.1 5.2 5.3 5.4 第6章 ライブラリについて ................................................................................... 7-2 ライブラリの検索、選択、スキャン .......................................................... 7-3 ARM ライブラリアン ................................................................................. 7-7 fromelf ユーティリティの使用 8.1 8.2 8.3 iv System V の共有ライブラリについて ........................................................ 6-2 SVr4 の共有ライブラリの使用 ................................................................... 6-3 ライブラリの作成と使用 7.1 7.2 7.3 第8章 スキャッタローディングについて .............................................................. 5-2 スキャッタローディング記述ファイルの正式な構文 ............................... 5-10 領域アドレスとセクションアドレスの指定の例 ...................................... 5-29 等価なスキャッタローディング記述を使用した単純イメージの生成 ..... 5-42 System V の共有ライブラリ 6.1 6.2 第7章 ARM と Thumb の同義語 ........................................................................... 4-2 リンカ定義シンボルへのアクセス .............................................................. 4-3 別のイメージに含まれるシンボルへのアクセス ........................................ 4-8 グローバルシンボルの非表示と名前の変更 ............................................. 4-12 $Super$$ と $Sub$$ を使用したシンボル定義のオーバーライド ........... 4-21 シンボルのバージョン管理 ...................................................................... 4-22 fromelf について ......................................................................................... 8-2 fromelf のコマンド構文 .............................................................................. 8-3 fromelf の使用例 ....................................................................................... 8-13 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 序章 本章では、RealView Compilation Tools リンカ / ユーティリティガイド(本書)について 概説します。本章は以下のセクションから構成されています。 • 本書について(P. vi) • ARM DUI 0206GJ フィードバック(P. ix) Copyright © 2002-2006 ARM Limited. All rights reserved. v 序章 本書について 本書では、RealView® Compilation Tools(RVCT)に関する参考情報を提供しています。 また、RVCT 付属のリンカで使用できるコマンドラインオプションと他の ARM® ツー ルについて説明します。 対象読者 本書は、RVCT を使用してアプリケーションを作成している開発者を対象としていま す。本書の内容は、RealView Compilation Tools v3.0 Essentials Guide で説明されている ARM 開発ツールを熟知した経験豊富なソフトウェア開発者を対象に書かれています。 本書の構成 本書は以下の章と付録から構成されています。 第 1 章 はじめに RVCT v3.0 付属のリンカと関連ユーティリティの概要を説明します。 第 2 章 リンカのコマンド構文 リンカに使用できるすべてのコマンドラインオプションについて説明し ます。 第 3 章 基本リンカ機能の使用 リンカの機能の使用方法と単純なイメージの作成方法を詳しく説明し ます。 第 4 章 イメージのシンボルへのアクセス イメージ内のシンボルにアクセスする方法について詳しく説明します。 第 5 章 スキャッタローディング記述ファイルの使用 スキャッタローディング記述ファイルを使用して、メモリ内にコードと データを配置する方法について詳しく説明します。 第 6 章 System V の共有ライブラリ System V の共有ライブラリの使用方法について詳しく説明します。 第 7 章 ライブラリの作成と使用 ライブラリオブジェクトの作成手順とライブラリオブジェクトにアクセ スする方法について説明します。 vi Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 序章 第 8 章 fromelf ユーティリティの使用 このユーティリティを使用してイメー fromelf ユーティリティの概要と、 ジ形式を変更する方法について説明します。 本書では、ARM ソフトウェアが標準設定の場所にインストールされていることを前提 と し て い ま す。例 え ば、Windows 環境では、標準設定の場所は volume:\Program Files\ARM になります。パス名を参照する際、install_directory の部分をこの場所に読 み替えて下さい。例えば、本書では、install_directory\Documentation\... のような パス名が使用されます。ARM ソフトウェアを別の場所にインストールした場合は、 ファイルパスの見方を変える必要があります。 表記規則 本書では以下の表記規則を使用しています。 monospace コマンド、ファイル名、プログラム名、ソースコードなど、キーボード から入力可能なテキストを示しています。 monospace コマンドまたはオプションに使用可能な略語を示します。コマンド名ま たはオプション名をすべて入力する代わりに、下線部分の文字だけを入 力することができます。 monospace italic コマンドまたは関数の引数で、特定の値に置き換えることが可能なもの を示しています。 monospace bold サンプルコード以外に使用される言語キーワードを示しています。 ARM DUI 0206GJ italic 重要事項、重要用語、相互参照、引用箇所を斜体で記載しています。 bold メニュー名などのユーザインタフェース要素を太字で記載しています。 また、適宜記述リスト内の重要箇所と ARM プロセッサの信号名にも太 字を用いています。 Copyright © 2002-2006 ARM Limited. All rights reserved. vii 序章 参考資料 ここでは、ARM プロセッサファミリのコード開発に関する補足情報を記載した ARM Limited および各社の出版物を紹介します。 ARM Limited は自社出版物の定期的な更新・修正を行っています。最新の正誤表、追 補表、ARM に関する FAQ については、http://www.arm.com をご覧下さい。 ARM の出版物 本書では、RVCT 付属の開発ツールの参考情報を提供しています。このほか、本製品に は以下のマニュアルが同梱されています。 • • RealView Compilation Tools v3.0 基本操作ガイド(ARM DUI 0202J) RealView Compilation Tools バージョン 3.0 コンパイラ / ライブラリガイド (ARM DUI 0205J) • RealView Compilation Tools v3.0 アセンブラガイド(ARM DUI 0204J) • RealView Compilation Tools v3.0 デベロッパガイド(ARM DUI 0203J) • RealView Development Suite 用語集(ARM DUI 0324J) base standard、ソフトウェアインタフェース、および ARM でサポートされている標準 に関する詳細については、install_directory\Documentation\Specifications\ を参照し て下さい。 特定の ARM 製品に関する情報については、以下のマニュアルを参照して下さい。 • ARM アーキテクチャリファレンスマニュアル(ARM DUI 0100J-00) • ARM Reference Peripheral Specification(ARM DDI 0062) • お使いのハードウェアデバイスの ARM データシートまたはテクニカルリファレ ンスマニュアル 他の出版物 本書は、ARM アセンブリ言語、C、および C++ プログラミング言語の概要を説明する ことを意図したものではありません。プログラミングに関する一般情報については、他 の出版物を参照して下さい。 ARM アーキテクチャの一般的な情報については、以下の出版物を参照して下さい。 Andrew N. Sloss, Dominic Symes and Chris Wright, ARM System Developer's Guide: Designing and Optimizing System Software (2004).Morgan Kaufmann, ISBN 1-558-60874-5. viii Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 序章 フィードバック ARM Limited では、RealView Compilation Tools および本書に関するフィードバックをお 待ちしております。 RealView Compilation Tools に関するフィードバック RVCT に関して問題がある場合は、購入元にお問い合わせ下さい。このとき、迅速かつ 適切な対応をさせて頂くために、以下の情報をご用意下さい。 • お名前と会社名 • 製品のシリアル番号 • 製品のリリース情報 • プラットフォームの詳細(ハードウェアプラットフォーム、オペレーティングシ ステムの種類とバージョンなど) • 問題を再現するサイズの小さな独立したサンプルコード • 操作の目的と実際の動作に関する詳しい説明 • 使用したコマンド(コマンドラインオプションを含む) • 問題を再現できるサンプル出力 • ツールのバージョン情報(バージョン番号、ビルド番号を含む) 本書に関するフィードバック 本書に関するご意見につきましては、以下の内容を記載した電子メールを [email protected] までお送り下さい。 • • • • マニュアル名 文書番号 問題のあるページ番号 問題点の簡潔な説明 補足すべき点や改善すべき点についてのご提案もお待ちしております。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. ix 序章 x Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 第1章 はじめに 本章では、RealView® Compilation Tools (RVCT)付属の ARM® リンカ armlink と、ユー ティリティプログラム armar および fromelf について説明します。本章は以下のセク ションから構成されています。 • RVCT について(P. 1-2) • ARM DUI 0206GJ リンカおよびユーティリティについて(P. 1-3) Copyright © 2002-2006 ARM Limited. All rights reserved. 1-1 はじめに 1.1 RVCT について RVCT は、ARM ファミリの Reduced Instruction Set Computing (RISC)プロセッサ向け アプリケーションを記述するための、サポートドキュメントやサンプルを含めたツー ルスイートで構成されています。RVCT を使用すると、C、C++、および ARM アセン ブリ言語で記述されたプログラムをビルドできます。 本書では、RVCT 付属の ARM リンカ armlink、イメージ変換ユーティリティ fromelf、 および ARM ライブラリアン armar について説明します。以前のリリースの RVCT から アップグレードする場合は、RealView Compilation Tools v3.0 Essentials Guide を読んで、 このリリースの新機能と拡張機能について確認して下さい。 RVCT を初めて使用する場合は、RealView Compilation Tools v3.0 Essentials Guide を読ん で、ARM ツールの概要と、ARM ツールを開発プロジェクトで使用する方法の概要を 確認して下さい。 RVCT の以前のリリースの詳細については、RealView Compilation Tools v3.0 Essentials Guide の付録 A を参照して下さい。 ARM アセンブラ、コンパイラ、およびサポートしているソフトウェアに関する情報が 「ARM の出版 記載された、RVCT 付属マニュアルの他のマニュアルの一覧については、 物」(P. viii)を参照して下さい。 1.1.1 サンプルの使用方法 本書では、RealView Development Suite に収録されているサンプルを参照します。これ らは、主なサンプルディレクトリの install_directory\RVDS\Examples にあります。収 録されているサンプルの概要については、RealView Development Suite スタートガイドを 参照して下さい。 1-2 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ はじめに 1.2 リンカおよびユーティリティについて このセクションでは、以下の概要を説明します。 • armlink 1.2.1 • fromelf(P. 1-4) • armar(P. 1-4) • 従来のオブジェクトおよびライブラリとの互換性(P. 1-4) armlink ARM リンカは 1 つ以上のオブジェクトファイルの内容と、1 つ以上のオブジェクトラ イブラリから選択された部分とを結合して、以下を生成します。 • ELF 形式の実行可能イメージ • 次のリンク手順への入力として使用可能な部分的にリンクされた ELF オブジェ クト • Base Platform ABI for the ARM Architecture [BPABI]や Sun の System V リリース 4 (SVr4)仕様と互換性のある共有オブジェクト、または BPABI や SVr4 実行可能 ファイル リンカは、リンク対象のオブジェクトのビルド属性に基づいて、リンクに適した標準 C ライブラリまたは C++ ライブラリのバリアントを自動的に選択します。 リンカは、ARM コード、Thumb® コード、および Thumb-2 コードをリンクして、必要 に応じてプロセッサ状態を切り替えるためのインターワークベニアを自動生成できま す。さらに、必要に応じて、インラインベニアまたは長分岐ベニアを自動生成し、分 岐命令の範囲を拡張できます。 ARM リンカは、システムメモリマップ内においてコードとデータの位置を指定できる コマンドラインオプションをサポートしています。また、スキャッタローディング記 述ファイルを使用して、ロード時と実行時のどちらでも、出力イメージ内のコードセ クションとデータセクションに別々のメモリ位置を指定できます。これにより、複数 のメモリにわたる複雑なイメージを作成できます。 ARM リンカは、ROM サイズを最小化するための読み出し / 書き込みデータ圧縮をサ ポートしています。 次にファイルをコンパイルするときのため、使用していない関数についてコンパイラ に通知するリンカフィードバックを提供します。フィードバックは、その後のコンパ イルで、関数自体のセクション内に配置され、リンカによって削除できるようになっ ています。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 1-3 はじめに リンカは、共通セクションの削除と未使用セクションの削除を実行して、出力イメー ジのサイズを縮小することができます。また、リンカを使用すると、以下の処理を行 うことができます。 • リンクされたファイルに関するデバッグ情報と参照情報の生成 • スタティックコールグラフの生成とそのスタック使用率の一覧の出力 • 出力イメージにあるシンボルテーブルの内容の制御 • 出力に含まれるコードとデータのサイズの表示 未使用の共通セクション以外にも、ARM リンカは共通グループやセクションの削除を 実行できます。Comdat (Common の ELF 名)グループの削除プロセスでは、共通セク ションの削除メカニズムと同じ条件を使用しています。 リンカは ELF 形式の出力のみを出力します。ELF 形式のイメージを ROM にロードす るためにプレーンバイナリ形式に変換するには、fromelf ユーティリティを使用しま 「fromelf」を参照して下さい。 す。詳細については、 ARM リンカとすべてのコマンドラインオプションの詳細については、「第 2 章 リンカ のコマンド構文」を参照して下さい。 1.2.2 fromelf fromelf は ARM のイメージ変換ユーティリティです。このユーティリティは、ELF 形 式の入力ファイルを受け取り、以下の多様な出力形式に変換します。 • プレーンバイナリ • Motorola 32 ビット S レコード形式 • Intel Hex 32 ビット形式 • バイト指向(Verilog メモリモデル)16 進形式 fromelf ユーティリティを使用すると、入力ファイルや逆アセンブルコードに関するテ キスト情報も生成できます。 詳細については、「第 8 章 fromelf ユーティリティの使用」を参照して下さい。 1.2.3 armar ARM ライブラリアン armar を使用すると、ELF 形式のファイル群を標準形式の ar ライ ブラリにまとめて保管できます。これにより、複数の ELF オブジェクトファイルの代 わりにライブラリをリンカに渡すことができます。 詳細については、「ARM ライブラリアン」(P. 7-7)を参照して下さい。 1.2.4 従来のオブジェクトおよびライブラリとの互換性 以前のリリースの RVCT からアップグレードする場合は、RealView Compilation Tools v3.0 Essentials Guide を読んで、RVCT の新しいリリースと以前のリリースとの間の互換 性について確認して下さい。 1-4 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 第2章 リンカのコマンド構文 本章では、RealView® Compilation Tools (RVCT)付属の ARM® リンカ armlink のコマン ド構文について詳しく説明します。本章は以下のセクションから構成されています。 • armlink について(P. 2-2) • ARM DUI 0206GJ armlink のコマンド構文(P. 2-10) Copyright © 2002-2006 ARM Limited. All rights reserved. 2-1 リンカのコマンド構文 2.1 armlink について このセクションでは、以下の内容について説明します。 • armlink への入力 • armlink からの出力 • コマンドラインオプションの順序(P. 2-4) 環境変数を使用したコマンドラインオプションの指定(P. 2-4) リンカオプションの概要(P. 2-5) • • 2.1.1 armlink への入力 armlink への入力には以下のものがあります。 2.1.2 • ELF オブジェクト形式のオブジェクトファイル(複数のファイルを指定すること もできます)。この形式は、ARM ELF 仕様書に記載されています。詳細について 「ARM の出版物」(P. viii)を参照して下さい。 は、 • armar によって作成されたライブラリ( 「第 7 章 ライブラリの作成と使用」参照)。 複数のライブラリを指定することもできます。 • シンボル定義ファイル。 armlink からの出力 armlink が正常に呼び出されると、以下のいずれかの出力が行われます。 • 実行可能な ELF 形式の実行可能イメージ • • 共有オブジェクト 部分的にリンクされた ELF オブジェクト形式のオブジェクト • 再配置可能な ELF イメージ 単純イメージの場合、ELF 形式の実行可能なファイルには、そのイメージの RO および RW 出力セクションとほぼ同じセグメントが含まれます。また、そのイメージの出力セ クションを含む ELF セクションもあります。 fromelf ユーティリティを使用して、実行可能な ELF 形式の実行可能イメージを他の ファイル形式に変換できます。詳細については、「第 8 章 fromelf ユーティリティの使 用」を参照して下さい。 2-2 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 実行可能イメージの作成 リンカを使用して実行可能イメージを作成するときは、以下の処理が行われます。 • 複数の入力オブジェクトファイル間のシンボリック参照を解決します。 • そのままでは不完全なシンボリック参照を解決するために、ライブラリからオブ ジェクトモジュールを抽出します。 • 入力セクションを属性と名前でソートし、類似する属性と名前の付いたセクショ ンを連続する塊にマージします。 • 未使用セクションを削除します。 • 重複する共通グループ、共通コードセクション、データセクション、およびデ バッグセクションを削除します。 • 指定されたグループ化と配置の情報に基づいて、オブジェクトの断片をメモリ領 域内に配置します。 • 再配置可能な値を再配置します。 • 実行可能イメージを生成します。 通常、ロード領域は、リセット時(例えば ROM 内)、またはデバッガによってイメー ジがターゲットにロードされた後、システムメモリマップ内に存在します。ただし、イ メージを実行する際に、領域をロードアドレスから実行アドレスに移動しなければな らない場合があります。そのため、イメージのメモリマップには、以下の 2 つの異な るビューがあります。 ロードビュー プログラムとデータが最初にロードされるときのメモリビュー 実行ビュー コードが通常の実行位置に移動された後のメモリビュー メモリマップの説明では、以下の用語に注意して下さい。 • ルート領域とは、ロードアドレスと実行アドレスが同じ領域のことです。 • ロード領域と ELF セグメントは同じものです。 イメージ階層の詳細については、「イメージ構造の指定」(P. 3-2)を参照して下さい。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-3 リンカのコマンド構文 部分的にリンクされたオブジェクトの作成 リンカを使用して部分的にリンクされたオブジェクトを作成するときは、以下の処理 が行われます。 • デバッグセクションの重複するコピーを削除します。 • シンボルテーブルのサイズを最小にします。 • 未解決の参照を未解決のままにします。 • Comdat グループをマージします。 • 次のリンク手順への入力として使用可能なオブジェクトを生成します。 注 部分的なリンクを使用する場合、スキャッタローディング記述ファイルでは、コンポー ネントオブジェクトを名前で参照することはできません。 2.1.3 コマンドラインオプションの順序 一般的に、コマンドラインオプションは 1 回のリンカ呼び出しにおいて任意の順序で 使用できます。ただし、その結果が、他の関連オプションとの組み合わせ方によって 変わるオプションもあります。例えば、--scatter オプションはどのメモリマップオプ (P. 2-15)参照)とも同時に指定するこ ション(「イメージのメモリマップ情報の指定」 とはできません。 オプションが同じコマンドラインにある前のオプションをオーバーライドする場合、 最後に指定されたオプションが優先されます。この規則に従っていないオプションに ついては、そのことが説明されています。--show_cmdline オプションを使用すると、リ ンカがどのようにコマンドラインを処理したかを確認できます。コマンドは正規化さ れて表示されます。また、via ファイルの内容は展開されます。 2.1.4 環境変数を使用したコマンドラインオプションの指定 コマンドラインオプションは、 RVCT30_LINKOPT 環境変数の値を設定することによって指 定できます。この構文は、コマンドライン構文と同じです。リンカは、RVCT30_LINKOPT の値を読み出し、コマンドストリングの前に挿入します。これにより、RVCT30_LINKOPT で指定されたオプションは、コマンドラインの引数によってオーバーライド可能にな ります。 2-4 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 2.1.5 リンカオプションの概要 このセクションでは、リンカの各コマンドラインオプションの概要について説明しま す。オプションは、機能グループ別にアルファベット順に分類しています。 ヘルプと情報へのアクセス 使用可能なコマンドラインオプションの情報を入手するには、以下のオプションを使 用します。 --help ツールのバージョン番号を確認するには、以下のオプションを使用します。 --vsn 入力ファイルリストの指定 リンカに渡す入力ファイルを指定するには、以下のオプションを使用します。 --input-file_list --libpath pathlist --scanlib | --no_scanlib --userlibpath pathlist POSIX オプション -- を使用すると、後続のすべての引数がコマンドスイッチではなく ファイル名として処理されるように指定できます。例えば、--scatter というファイル をリンクするには、以下のように入力します。 armlink -- --scatter リンカ動作の制御 オブジェクトを相互にリンクする方法を定義するには、以下のオプションを使用し ます。 --match crossmangled --strict --unresolved symbol ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-5 リンカのコマンド構文 出力形式と出力ファイル名の指定 出力ファイルを指定するには、以下のオプションを使用します。 --output file 実行可能イメージではなく、部分的にリンクされたオブジェクトを作成するには、以 下のオプションを使用します。 --partial 共有オブジェクトまたは実行可能ファイルの形式を指定するには、以下のオプション を使用します。 --shared --sysv 再配置可能なオブジェクトを作成するには、以下のオプションを使用します。 --reloc イメージのメモリマップ情報の指定 単純なメモリマップを指定するには、以下のオプションを使用します。 --fpic --ro-base address --rw-base address --ropi --rwpi --rosplit --split 複雑イメージの場合、メモリマップを指定するには、以下のオプションを使用します。 --pad num --scatter file --scatter オプションを使用する場合、スキャッタローディング記述ファイルと、 (可 能であれば)__user_initial_stackheap() 関数の再実装を指定する必要があります。詳 「第 5 章 スキャッタローディング記述ファイルの使用」を参照して下さ 細については、 い。 メモリマップオプションでは、実行可能イメージのメモリマップが指定されるため、部 分的なリンクには使用できません。詳細については、RealView Compilation Tools v3.0 Developer Guide を参照して下さい。 2-6 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 デバッグ情報の制御 デバッグ情報を制御するには、以下のオプションを使用します。 --compress_debug --debug | --no_debug --dynamic_debug --no_bestdebug | --bestdebug イメージ内容の制御 イメージの内容に影響するさまざまな要因を制御するには、以下のオプションを使用 します。 --cppinit symbol --datacompressor on|off|list|id --dynamiclinker name --edit file-list --entry location --exceptions | --no_exceptions --exceptions_tables=action --fini symbol --first section-id --force_so_throw --init symbol --inline --keep section-id --last section-id --linux_abitag version-id --locals | --no_locals --no_branchnop --pt_arm_exidx --remove | --no_remove --soname name --startup symbol --symver_script file --symver_soname --tailreorder --vfemode=mode ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-7 リンカのコマンド構文 ベニア生成の制御 ベニアの生成方法を制御するには、以下のオプションを使用します。 --no_inlineveneer --no_veneershare バイトアドレシングモードの指定 バイトアドレシングモードを制御するには、以下のオプションを使用します。 --be8 --be32 イメージ関連情報の生成 イメージに関する情報を抽出および表示する方法を制御するには、以下のオプション を使用します。 --callgraph --feedback file --info topics --list_mapping_symbols --mangled | --unmangled --map --symbols --symdefs file --xref --xrefdbg --xreffrom object(section) --xrefto object(section) --callgraph を指定した場合を除き、リンカでは要求された情報が標準の設定では標準 出力ストリーム stdout に出力されます。--list コマンドラインオプションを使用する と、この情報をテキストファイルに転送できます。 --callgraph を指定すると、この情報が output_name.htm という名前の HTML ファイル に保存されます。このファイルは、生成されたイメージと同じディレクトリに保存さ れます。 2-8 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 リンカの診断の制御 リンカによる診断情報の生成方法を制御するには、以下のオプションを使用します。 --diag_style arm|ide|gnu --diag_suppress taglist --diag_warning taglist --errors file --list file --verbose via ファイルの使用 リンカのコマンドラインに追加する引数を含む via ファイルを指定するには、以下のオ プションを使用します。 --via file 詳細については、RealView Compilation Tools v3.0 Compiler and Libraries Guide の via ファ イルに関するセクションを参照して下さい。 その他 厳密に ELF に準拠したアウトプットが必要な場合は、以下のオプションを使用します。 --no_legacyalign ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-9 リンカのコマンド構文 2.2 armlink のコマンド構文 このセクションでは、armlink のコマンド構文とオプションについて説明します。 注 かっこを使用するコマンドライン引数の場合、Sun Solaris システムや Red Hat Linux シ ステムでは、バックスラッシュ(\)文字を使用してかっこ文字をエスケープする必要 がある場合があります。 コマンドラインのキーワードを指定するには、ダッシュを 2 つ(--)使用します(例 : --partial)。ADS と RVCT の以前のバージョンで使用されていた単一ダッシュコマン ドラインオプションは、以前のバージョンとの互換性を維持するために引き続きサ ポートされますが、現在使用が制限されています。 以下にリンカのコマンド構文を示します。 armlink [help-options] [input-file-list] [linker-control-options] [output-format] [memory-map-options] [debug-options] [image-contents-options] [veneer-generation-options] [Byte Addressing mode] [image-info-options] [diagnostics-options] [via-file] 本章の残りの部分では、これらのオプションについて詳しく説明します。 • ヘルプと情報へのアクセス(P. 2-11) • • • • • • • • • • • • • 2-10 入力ファイルリストの指定(P. 2-11) リンカ動作の制御(P. 2-13) 出力形式と出力ファイル名の指定(P. 2-14) イメージのメモリマップ情報の指定(P. 2-15) デバッグ情報の制御(P. 2-18) イメージ内容の制御(P. 2-19) ベニア生成の制御(P. 2-29) バイトアドレシングモードの指定(P. 2-29) イメージ関連の情報の生成(P. 2-30) リンカの診断の制御(P. 2-35) via ファイルの使用(P. 2-37) その他(P. 2-37) 従来のオブジェクトとの互換性の制御(P. 2-37) Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 2.2.1 ヘルプと情報へのアクセス 使用可能なコマンドラインオプションの情報とツールのバージョン番号を取得するに は、以下のオプションを使用します。 2.2.2 --help よく使用されるいくつかのコマンドラインオプションの一覧を出力し ます。 --vsn リンカのバージョン情報とライセンス情報を表示します。 入力ファイルリストの指定 リンカに渡す入力ファイルを指定するには、以下のオプションを使用します。 input-file-list オブジェクト、ライブラリ、またはシンボル定義(symdefs)ファイルを スペースで区切って指定します。 このリストに symdefs ファイルを含めることで、前に生成されたイメー ジファイルのグローバルシンボル値を指定できます。詳細については、 「別のイメージに含まれるシンボルへのアクセス」 (P. 4-8)を参照して下 さい。 入力ファイルリスト内のライブラリは、以下の方法で使用できます。 • 非 weak 型の未解決参照を解決するメンバがある場合に追加する、 そのメンバの抽出に使用するライブラリをライブラリリストに指 定します。例えば、入力ファイルリストに mystring.lib と指定し ます。 リンカが標準の設定のライブラリディレクトリをスキャンし、ほぼ 一致する使用可能なライブラリバリアントを選択する場合に、標準 C または C++ ライブラリがこのリストに暗黙に追加されます。 注 このリストのライブラリのメンバは、非 weak 型の参照を解決する 場合のみ、イメージに追加されます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-11 リンカのコマンド構文 • ライブラリから抽出し、個別のオブジェクトとしてイメージに追 加する特定のメンバを指定します。例えば、入力ファイルリスト に mystring.lib(strcmp.o) と指定します。 リンカでは、入力ファイルリストが以下の順序で処理されます。 1. オブジェクトを無条件にイメージに追加します。 2. パターンを使用してライブラリから選択したメンバを、オブジェ クトとして無条件にイメージに追加します。例えば、以下のコマ ンドでは、mylib の a*.o という名前のすべてのオブジェクトと stdio.o が無条件に追加されます。 armlink main.o mylib(stdio.o) mylib(a*.o) UNIX システムでは、以下のようにかっこをエスケープする必要が あります。 armlink main.o mylib\(stdio.o\) 3. 残りの非 weak 型の未解決参照の解決のために後で使用する標準 C または C++ ライブラリをリストに追加します。 「ライブラリの検索、選択、スキャン」(P. 7-3)を参照 詳細については、 して下さい。 --libpath pathlist ARM の標準 C および C++ ライブラリの検索に使用されるパスのリスト を指定します。 ARM のライブラリを含むペアレントディレクトリの標準設定のパスは、 RVCT30LIB 環境変数で指定されます。ここで指定したすべてのパスは、 RVCT30LIB で指定されたパスをオーバーライドします。 pathlist には、必要な ARM ライブラリの検索のみに使用するパスをコン マで区切って指定します。複数のパス名を指定するときは、コンマとパス 名の間にスペースを含めないで下さい(例、path1,path2,path3,...,pathn) 。 このリストは、ARM のライブラリディレクトリ armlib および cpplib の ペアレントディレクトリで終わる必要があります。 注 このオプションは、ユーザライブラリの検索には影響しません。ユーザ ライブラリの検索には --userlibpath を使用して下さい。 ライブラリのインクルードに関する詳細については、 「ライブラリの検 索、選択、スキャン」(P. 7-3)を参照して下さい。 2-12 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 --scanlib 標準の設定のライブラリ(標準 ARM C および C++ ライブラリ)のスキャ ンをイネーブルして、参照を解決します。これが標準の設定です。 --no_scanlib 標準の設定のライブラリのスキャンをディセーブルします。 --userlibpath pathlist ユーザライブラリの検索に使用されるパスのリストを指定します。 pathlist には、必要なライブラリの検索のみに使用するパスをコンマで 区切って指定します。複数のパス名を指定するときは、コンマとパス名 の間にスペースを含めないで下さい(例 : path1,path2,path3,...,pathn)。 ユーザライブラリのインクルードに関する詳細については、 「ライブラリ の検索、選択、スキャン」(P. 7-3)を参照して下さい。 2.2.3 リンカ動作の制御 オブジェクトのリンク方法を制御するには、以下のオプションを使用します。 --match crossmangled 以下の組み合わせのマッチングを行うようにリンカに指示します。 • 符号化されていないシンボルへの参照と符号化された定義 • 符号化されたシンボルへの参照と符号化されていない定義 ライブラリとマッチング操作は以下のように行われます。 • ライブラリのメンバによって符号化された定義が定義されてい て、符号化されていない未解決の参照が存在する場合、このよう な参照を解決するためにメンバをロードします。 • ライブラリのメンバによって符号化されていない定義が定義され ていて、符号化された未解決の参照が存在する場合、このような 参照を解決するためにメンバをロードします。 注 このオプションを部分的なリンクに使用しても機能しません。部分的に リンクされたオブジェクトには、符号化された定義が存在する場合でも、 符号化されていないシンボルへの未解決の参照がすべて保持されます。 マッチングは、リンクの最終手順でのみ行われます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-13 リンカのコマンド構文 --strict 障害を引き起こす可能性のある状態を、警告ではなくエラーとしてレ ポートするようにリンカに指示します。このような状態の例には、イン ターワーク用にコンパイルされていない関数からインターワーク関数の アドレスを受け取る場合などがあります。 --strict_relocations 廃止され、現在使用が制限されている再配置の例をレポートするように リンカに指示します。以下に例を示します。 Error: L6810E: Relocation 8 in section relocs from object et5ae.o is of obsolete type R_ARM_SWI24. 多くの場合、再配置のエラーと警告は、前のバージョンの ARM ツール でビルドされたオブジェクトファイルをリンクしている場合に発生し ます。 このオプションを使用すると、オブジェクトは ABI 準拠になります。標 準ではこのオプションは無効になっており、廃止されています。現在使 用が制限されている再配置は自動的に処理されます。 --unresolved symbol 未定義シンボルへの各参照と、symbol のグローバル定義とのマッチング を行います。symbol は、定義済みかつグローバルでなければなりません。 それ以外のシンボルは未定義シンボルとして一覧され、リンク手順が失 敗します。このオプションを使用すると、見つからない関数への各参照 とダミー関数とのマッチングを行うことによって、部分的に実装された システムをテストできる為、トップダウン方式の開発に特に役立ちます。 2.2.4 出力形式と出力ファイル名の指定 出力ファイルの形式と名前を指定するには、以下のオプションを使用します。 --output file 出力ファイルの名前を指定します。出力ファイルには、部分的にリンク されたオブジェクトと実行可能イメージのいずれかを指定できます。出 力ファイル名が指定されていないと、以下の標準の名前が使用されます。 __image.axf 出力が実行可能イメージの場合 __object.o 出力が部分的にリンクされたオブジェクトの場合 file にパス情報が指定されていない場合、現在の作業ディレクトリに ファイルが作成されます。パス情報が指定されている場合は、そのディ レクトリが標準の設定の出力ディレクトリになります。 2-14 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 --partial 実行可能イメージではなく、部分的にリンクされたオブジェクトを作成 します。 --reloc ELF イメージを再配置可能にします(詳細については、ARM ELF 仕様書 を参照して下さい)。 再配置可能なイメージには、リンク後のイメージの再配置に使用できる 再配置アドレスを保持する動的セグメントが含まれます。リンク後の再 配置の例には、拡張 ROM 構築やランタイム時の動的なロードなどがあ ります。 イメージをリンク時のアドレスにロードする場合は、リンカで作成され る再配置可能なイメージに再配置の処理を行う必要はなく、イメージ内 のデバッグデータは有効です。しかし、イメージをリンク時のアドレス とは異なるアドレスにロードし、再配置の処理を行うと、イメージ内の すべてのデバッグデータが無効になります。 --reloc を単独で使用すると、ロード領域の属性が RELOC に設定される、 単純タイプ 1 に似たイメージを生成します(詳細については、 「タイプ 1:1 つのロード領域と連続する出力領域」 (P. 3-29)を参照して下さい)。 --shared SVr4 共有オブジェクトを生成します。 詳細については、 「第 6 章 System V の共有ライブラリ」を参照して下さい。 --sysv ARM Linux で使用できる SVr4 形式の ELF 実行可能ファイルの生成をイ ネーブルします。 詳細については、 「第 6 章 System V の共有ライブラリ」を参照して下さい。 2.2.5 イメージのメモリマップ情報の指定 メモリマップを指定するには、以下のオプションを使用します。 --ro-base address RO 出力セクションを含む領域のロードアドレスと実行アドレスの両方 に address を設定します。address はワード境界で整列される必要があり ます。このオプションもスキャッタローディング記述ファイルも指定し ないと、標準の設定の RO ベースアドレスは 0x8000 になります。 --rw-base address RW 出力セクションを含む領域の実行アドレスに address を設定します。 address はワード境界で整列される必要があります。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-15 リンカのコマンド構文 --ropi --rwpi RO 出力セクションを含むロード領域と実行領域が位置に依存しなくな ります。このオプションを使用しない場合、領域は絶対としてマークさ れます。読み出し専用の入力セクションは、読み出し専用の位置非依存 (ROPI)にする必要があります。このオプションを使用すると、リンカ は以下の処理を行います。 • セクション間の再配置が有効であることをチェックします。 • インターワークベニアなど、armlink 自体によって生成されたすべ てのコードが、読み出し専用の位置に非依存であることを確認し ます。 RW 出力セクションと ZI 出力セクションを含むロード領域と実行領域が 位置に依存しなくなります。このオプションを使用しない場合、領域は 絶対としてマークされます。このオプションには、--rw-base の値が必要 です。--rw-base を指定しないと、--rw-base 0 を指定したと見なされま す。通常、書き込み可能な入力セクションは、読み出し - 書き込み可能 な位置非依存(RWPI)にする必要があります。 このオプションを選択すると、リンカは以下の処理を行います。 • すべての読み出し - 書き込み可能な実行領域への入力セクション に、PI 属性が設定されていることをチェックします。 • セクション間の再配置が有効であることをチェックします。 • テーブル Region$$Table にベース相対の静的エントリを生成します。 このテーブルは、領域がコピー、伸張、または初期化されるとき に使用します。 --fpic /fpic 修飾子を使用してコンパイルされた位置非依存のコード(PIC)の リンクをイネーブルします。コードで System V の共有ライブラリを使用 している場合にのみ、参照アドレスが実装されます。 --split RO 出力セクションと RW 出力セクションを含む標準の設定のロード領 域を、以下のロード領域に分割します。 • RO 出力セクションを含む領域。標準の設定のロードアドレスは 0x8000 ですが、--ro-base オプションで異なるアドレスを指定で きます。 • RW 出力セクションと ZI 出力セクションを含む領域。ロードアドレ スは --rw-base オプションで指定します。このオプションには、 --rw-base の値が必要です。--rw-base を指定しないと、--rw-base 0 を指定したと見なされます。 この 2 つの領域はルート領域です。 2-16 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 --rosplit 標準の設定の RO ロード領域を、RO-CODE に 1 つ、RO-DATA に 1 つ、合計 2 つの RO 出力セクションに分割します。 --pad num パディングバイトの値を設定します。リンカでは、ロード領域または 実行領域に挿入されるすべてのパディングバイトにこの値を割り当て ます。 num には、16 進形式の整数を指定できます。例えば、num に 0xFF を設定 することで、ROM のプログラミング時間を短縮できる場合があります。 num の値が 0xFF よりも大きい場合は、パディングバイトに (char)num が 設定されます。 注 パディングの挿入には、以下の制限があります。 • パディングはロード領域内に挿入されます。ロード領域とロード 領域の間には、パディングは挿入されません。 • パディングは固定実行領域と固定実行領域の間に挿入されます (同時に境界調整の設定も行います)。ロード領域の先頭に固定実 行領域がある場合を除き、ロード領域の最大長までパディングが 挿入されることはありません。 • 境界調整の制約に確実に準拠するために、セクションとセクショ ンの間にパディングが挿入されます。 --scatter file file に指定されたスキャッタローディング記述ファイルを使用してイ メージのメモリマップを作成します。この記述ファイルには、イメージ 内のさまざまな領域およびセクションのグループ化と配置に関する詳細 が記述されています。詳細については、「第 5 章 スキャッタローディン グ記述ファイルの使用」を参照して下さい。 --scatter オプションは、メモリマップオプションの --ro-base、 --rw-base、--ropi、--rwpi、--rosplit、--split のいずれか、および --reloc、--startup、--partial と同時に指定することはできません。 注 このオプションを使用する場合は、スタックとヒープの初期化関数 __user_initial_stackheap() の再実装が必要になる場合があります。詳 「第 5 章 スキャッタローディング記述ファイルの使用」を 細については、 参照して下さい。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-17 リンカのコマンド構文 2.2.6 デバッグ情報の制御 イメージ内のデバッグ情報を制御するには、以下のオプションを使用します。 --debug 出力ファイルにデバッグ情報をインクルードします。デバッグ情報には、 デバッグ入力セクション、シンボルテーブル、およびストリングテーブ ルが含まれます。これが標準の設定です。 --no_debug 出力ファイルにデバッグ情報をインクルードしません。ELF イメージの サイズは小さくなりますが、ソースレベルでのデバッグはできません。 リンカでは、入力オブジェクトとライブラリのメンバ内にあるデバッグ 入力セクションを破棄し、イメージにシンボルとストリングテーブルを 含めません。このオプションは、デバッガにロードされるときのイメー ジのサイズのみに影響します。ターゲットにダウンロードされる最終的 なバイナリイメージのサイズには影響しません。 イメージではなく、部分的にリンクされたオブジェクトを作成している 場合、入力オブジェクトで検出されるデバッグ入力セクションが破棄さ れ、部分的にリンクされたオブジェクトにシンボルとストリングテーブ ルが生成されるようにリンカが設定されます。 注 fromelf --fieldoffsets を指定する必要がある場合は、--no_debug を使 用しないで下さい。デバッグ情報を持たないイメージを生成した場合、 fromelf ユーティリティには、以下の制限があります。 • • イメージを別の形式のファイルに変換できません。 分かりやすい逆アセンブルリストを生成できません。 --no_bestdebug デバッグ情報への参照を含まないセクションを選択します。つまり、最 もサイズが小さいセクションを選択します。 --no_bestdebug が標準の設定であり、デバッグ用にコンパイルしたかど うかにかかわらず、最終イメージのコードとデータが確実に同じになる ようにします。 --bestdebug オプションを使用すると、最適なデバッグビューを備えたセ クションが選択されます。最終イメージのコードとデータは、デバッグ 用にビルドしたかどうかによって同じにならない場合があることに注意 して下さい。 2-18 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 --compress_debug .debug_* セクションを強制的に圧縮するようにリンカに指示し、冗長性 を取り除き、デバッグテーブルのサイズを拡張します。 標準の設定では、デバッグテーブルの最適化は無効になっています。た だし、--compress_debug オプションを使用すると、リンク時間が長くな ります。 --dynamic_debug デバッグセクションのダイナミックな再配置を出力するようにリンカに 指示します。 このオプションを使用すると、RealView Debugger with Linux OS Awareness などの OS 対応のデバッガから armlink によって作成された共有ライブ ラリをデバッグできます。 --dynamic_debug は、--sysv および --sysv --shared で生成したイメー ジや共有ライブラリに対して使用します。 詳細については、 「第 6 章 System V の共有ライブラリ」を参照して下さい。 詳細については、RealView Compilation Tools v3.0 Compiler and Libraries Guide の ARM コ ンパイラの使用方法に関する章の「デバッグ情報の生成」を参照して下さい。 2.2.7 イメージ内容の制御 イメージの内容に影響するさまざまな要因を制御するには、以下のオプションを使用 します。 --datacompressor on|off ROM サイズを小さくするため、RW データ圧縮は標準の設定でイネー ブルになっています。RW データ圧縮をディセーブルするには、 --datacompressor off オプションを使用します。 --datacompressor list|id RW データ圧縮用に用意されているアルゴリズムのいずれかを指定でき ます。 • リンカに使用できるデータコンプレッサの一覧を取得するには、 --datacompressor list を使用します。 • ARM DUI 0206GJ データ圧縮アルゴリズムを指定しないと、最適なアルゴリズムが 自動的に選択されます。通常、この自動選択をオーバーライドす る必要はありません。詳細については、 「RW データ圧縮」 (P. 3-18) を参照して下さい。 Copyright © 2002-2006 ARM Limited. All rights reserved. 2-19 リンカのコマンド構文 自動的に選択されたアルゴリズムをオーバーライドする場合は、 --datacompressor id を使用してデータ圧縮アルゴリズムを指定し ます。コンプレッサを指定すると、コードエリアにデコンプレッ サが追加されます。最終イメージに圧縮されたデータが含まれて いない場合、デコンプレッサは追加されません。 --edit file-list 出力バイナリのシンボルテーブルを編集するコマンドを含むステアリン グファイルを指定します。ステアリングファイルには以下のことを行う コマンドを指定できます。 • グローバルシンボルを非表示にします。このオプションを使用す ると、オブジェクトファイル内の特定のシンボルを非表示にでき ます。非表示にしたシンボルは、パブリックには表示されません。 • グローバルシンボルの名前を変更します。このオプションを使用 すると、シンボル名の競合を解決できます。 「グローバルシンボルの ステアリングファイルの構文の詳細については、 非表示と名前の変更」(P. 4-12)を参照して下さい。 複数のステアリングファイルを指定する場合の構文は、以下のいずれか を使用できます。 armlink --edit file1 --edit file2 --edit file3 armlink --edit file1,file2,file3 コンマとファイル名の間にスペースを含めないで下さい。 --entry location イメージ固有の初期エントリポイントを指定します。イメージには複数 のエントリポイントを含めることができますが、このオプションを使用 して指定された初期エントリポイントは、ローダで使用できるように実 行可能ファイルのヘッダに保存されます。このオプションはコマンドラ イン内で 1 回のみ指定できます。RealView Debugger や AXD などの ARM デバッガでイメージをロードするとき、このエントリアドレスを使用し てプログラムカウンタ(PC)を初期化します。初期エントリポイントは、 以下の条件を満たしている必要があります。 • イメージのエントリポイントは、実行領域内にある必要があります。 • 実行領域は、オーバーレイでないルート実行領域(ロードアドレ ス == 実行アドレス)である必要があります。 location には以下のいずれかを指定します。 entry_address 数値。以下に例を示します。 --entry 0x0 symbol イメージのエントリポイントを symbol のアドレスとして指定 します。以下に例を示します。 --entry reset_handler 2-20 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 offset+object(section) イメージのエントリポイントを特定の object 内の section 内 にある offset として指定します。以下に例を示します。 --entry 8+startup.o(startupseg) --entry の引数内にはスペースを含めないで下さい。入力セク ションとオブジェクト名では大文字と小文字が区別されませ ん。以下の単純な表記を使用できます。 • object(section)、offset が 0 の場合。 • object、入力セクションが 1 つだけの場合。armlink か ら、object 内に複数の入力セクションが存在するとエ ラーメッセージが生成されます。 --exceptions 最終イメージに例外テーブルを含めます。これが標準の設定です。 詳細については、「コマンドラインオプションを使用した C++ 例外の処 理」(P. 3-34)を参照して下さい。 --no_exceptions 未使用セクションの削除後イメージに例外セクションが含まれる場合は エラーメッセージを生成するようにリンカに指示します。このオプショ ンを使用すると、コードでは例外が処理されません。 詳細については、「コマンドラインオプションを使用した C++ 例外の処 理」(P. 3-34)を参照して下さい。 --exceptions_tables=action 従来のオブジェクトの例外テーブルの生成方法を指定します。action に は以下のいずれかを指定します。 nocreate リンカでは、従来のオブジェクトの例外テーブルを作成しま せん。これが標準の設定です。 unwind リンカでは、例外テーブルを含んでいないイメージのセク ションごとに unwind テーブルを作成します。 cantunwind リンカでは、例外テーブルを含んでいないイメージのセク ションごとに nounwind テーブルを作成します。 詳細については、「コマンドラインオプションを使用した C++ 例外の処 理」(P. 3-34)を参照して下さい。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-21 リンカのコマンド構文 --first section-id 選択した入力セクションを実行領域の最初に配置します。例えば、ベク タテーブルを含むセクションをイメージの最初に配置することができま す。section-id には以下のいずれかを指定します。 symbol symbol を定義するセクションを選択します。最初に配置でき るセクションは 1 つだけなので、複数の定義を含むシンボル は指定しないで下さい。以下に例を示します。 --first reset object(section) object から section を選択します。object と開きかっこの間 にはスペースを含めないで下さい。以下に例を示します。 --first init.o(init) object 内の 1 つの入力セクションを選択します。この短縮形 を 使 用 し た 場 合 に 複 数 の 入 力 セ ク シ ョ ン が 存 在 す る と、 armlink からエラーメッセージが生成されます。以下に例を示 します。 object --first init.o 注 スキャッタローディングを使用しているときは、スキャッタローディン グ記述ファイルで +FIRST を使用します。 --first を使用しても、 領域内の出力セクションの基本属性ソート順序を オーバーライドできません。基本属性ソート順序では、RO、RW、ZI の 順に配置されます。RO セクションが存在する領域では、RW セクション または ZI セクションを最初に配置できません。また、RO セクションま たは RW セクションが存在する領域では、ZI セクションを最初に配置で きません。 2 つの異なるセクションを同じ実行領域の最初に配置することはできま せん。そのため、このオプションは 1 つしか使用できません。 2-22 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 --last section-id 選択した入力セクションを実行領域の最後に配置します。例えば、この オプションを使用すると、チェックサムを含む入力セクションを RW セ クションの最後に配置できます。section-id には以下のいずれかを指定 します。 symbol symbol を定義するセクションを選択します。最後に配置でき るセクションは 1 つだけなので、複数の定義を含むシンボル は指定しないで下さい。以下に例を示します。 --last checksum object(section) object から section を選択します。object と開きかっこの間 にはスペースを含めないで下さい。以下に例を示します。 --last checksum.o(check) object 内の 1 つの入力セクションを選択します。object 内に 複数の入力セクションが存在する場合は、armlink からエラー メッセージが生成されます。 object 注 スキャッタローディングを使用しているときは、スキャッタローディン グ記述ファイルで +LAST を使用します。 --last を使用しても、領域内の出力セクションの基本属性ソート順序を オーバーライドできません。基本属性ソート順序では、RO、RW、ZI の 順に配置されます。ZI セクションが存在する領域では、RW セクション を最後に配置できません。また、RW セクションまたは ZI セクションが 存在する領域では、RO セクションを最後に配置できません。 2 つの異なるセクションを同じ実行領域の最後に配置することはできま せん。そのため、このオプションは 1 つしか使用できません。 --remove 入力セクションでの未使用セクションの削除をイネーブルにして、イ メージから未使用セクションを削除します。入力セクションにイメージ のエントリポイントが含まれる場合、または入力セクションが使用され ているセクションから参照されている場合、その入力セクションは使用 されていると見なされます。「未使用セクションの削除」(P. 3-12)も参 照して下さい。 注 --remove を使用するときは、リセットコードや例外ハンドラを間違って 削除しないように注意する必要があります。--keep オプションを使用し て例外ハンドラを特定するか、ENTRY ディレクティブを使用して例外ハン ドラにエントリポイントとしてラベルを付けて下さい。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-23 リンカのコマンド構文 --remove (RO/RW/ZI/DBG) 注 セクション属性修飾子を指定した --remove のサポートは、現在使用が制 限されており、今後のリリースでは廃止される予定です。 --remove は、--remove (RO/RW/ZI/DBG) と同じ意味になります。 --no_remove 入力セクションでの未使用セクションの削除をディセーブルします。こ のオプションを使用すると、未使用の入力セクションがあっても、すべ ての入力セクションが最終イメージに含まれます。 --startup symbol リンカで起動シンボルが異なる代替の C ライブラリを使用します。リン カで main() の定義が検出され、symbol への参照(または定義)が検出さ れない場合、symbol への参照が追加されます。標準の設定では、symbol は __main に設定されます。 ライブラリの使用に関する詳細については、RealView Compilation Tools v3.0 Compiler and Libraries Guide の C および C++ ライブラリについて説 明した章を参照して下さい。 --symver_script file 暗黙のシンボルバージョン管理を有効にし、シンボルバージョンスクリ プトとして file を指定できます。 詳細については、「シンボルのバージョン管理」(P. 4-22)を参照して下 さい。 --symver_soname 暗黙のシンボルバージョン管理を有効にし、シンボルのバージョン管理 を行って静的バインドを行います。シンボルにバージョンが定義されて いない場合、リンクしているファイルの SONAME が使用されます。 BPABI 互換の実行可能ファイルを生成していても、オプション --symver_script を使用してバージョンスクリプトを指定していない場 合は、ここでの指定が標準の設定になります。 詳細については、 「シンボルのバージョン管理」 (P. 4-22)と Base Platform ABI for the ARM Architecture [BPABI]を参照して下さい。 2-24 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 --soname name 共有オブジェクトのランタイム名を指定します。ランタイム名は、この 共有オブジェクトに対してリンクされるすべてのオブジェクトで依存関 係名として使用されます。この依存関係は、リンカによって作成される 実行可能ファイルに保存されます。 「第 6 章 System V の共有ライブラリ」を参照して下さい。 詳細については、 --force_so_throw 標準の設定では、コードで例外がスローされない場合は例外テーブルが 破棄されます。このオプションを使用して、すべての共有オブジェクト が例外をスローする可能性があることを指定し、イメージが例外をス ローできるかどうかとは無関係に、例外テーブルを保持するようにリン カに指示します。 「第 6 章 System V の共有ライブラリ」を参照して下さい。 詳細については、 --pt_arm_exidx このオプションを使用すると、動的な内容を含むオブジェクトの例外 テーブルの場所を記述する PT_ARM_EXIDX プログラムヘッダを作成でき ます。リンカではこのヘッダにより、共有オブジェクトが例外をスロー する可能性があり、例外をスローできるかどうかとは無関係に例外テー ブルを保持します。 詳細については、 「第 6 章 System V の共有ライブラリ」を参照して下さい。 --dynamiclinker name ランタイム時にファイルのロードと再配置に使用する動的リンカを指定 します。共有オブジェクトとリンクする場合、動的リンカでは、実行可 能ファイルに保存された依存関係情報を使用してロードするファイルを 特 定 し ます。ARM Linux プラットフォームで作業している場合は、 /lib/ld-linux.so.2 が標準の設定の動的リンカと見なされます。 詳細については、 「第 6 章 System V の共有ライブラリ」を参照して下さい。 --linux_abitag version-id ビルドしている実行可能ファイルに対して、最小限の互換性のある Linux カーネルバージョンを指定します。 「第 6 章 System V の共有ライブラリ」を参照して下さい。 詳細については、 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-25 リンカのコマンド構文 --vfemode=mode 仮想関数の削除(VFE)は、リンカで多くの未使用セクションを識別で きるようにする技法です。このオプションを使用すると、リンカ内で未 使用セクションとランタイム型情報(RTTI)オブジェクトを削除する方 法を指定できます。リンカでは、指定されたモードに応じて、コンパイ ラから提供される仮想関数や RTTI オブジェクトに関する追加情報を使 用して、このような関数が使用されている方法をさらに正確に分析しま す。その後、未使用セクションを削除します。 mode には以下のいずれかを指定します。 on リンカを VFE 対応にします。このモードでは、リンカはオブ ジェクトファイルの内容に基づいて force モードまたは off モードを選択します。これが標準の設定です。 これは、コマンドラインで VFE オプションを指定しないのと 同じ意味です。 off コンパイラから提供される追加情報を無視するようにリンカ に指示します。このモードでは、最終イメージは VFE に対応 していないコンパイルおよびリンクによって生成されるイ メージと同じになります。 force リンカを VFE に対応し、VFE アルゴリズムの強制的な適用を 指示します。オブジェクトファイルの一部に VFE 情報が含ま れていない場合、リンカは削除を続行しますが、エラーが発 生する可能性があることを示す警告を生成します。 force_no_rtti (--vfemode=on を使用して)標準の設定のモードで操作してい る場合、リンカは未使用セクションと RTTI オブジェクトの 両方を削除することがあります。このオプションを使用する と、リンカを VFE に対応し、すべての仮想セクションを保持 したまま、すべての RTTI オブジェクトを削除することがで きます。 「未使用関数の削除」(P. 3-13)も参照して下さい。 詳細については、 --init symbol 初期化コードの定義に使用するシンボル名を指定します。実行可能ファ イルまたは共有オブジェクトをロードするときに、動的リンカによって このコードが実行されます。 「第 6 章 System V の共有ライブラリ」を参照して下さい。 詳細については、 2-26 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 --cppinit symbol リンカで初期化シンボルが異なる別の C++ ライブラリを使用します。標 準の設定では、symbol は __cpp_initialize__aeabi_ に設定されます。 ライブラリの使用に関する詳細については、RealView Compilation Tools v3.0 Compiler and Libraries Guide の C および C++ ライブラリについて説 明した章を参照して下さい。 --no_branchnop リンカでは、次の命令に解決することで再配置を行うすべての分岐を NOP に置き換えます。これが標準の設定です。 このオプションを使用すると、この動作をディセーブルできます。 「分岐のインライン 分岐のインライン化の制御に関する詳細については、 化」(P. 3-24)を参照して下さい。 --inline 分岐をインライン化して、イメージ内の小さな関数呼び出しを最適化し ます。 注 分岐の最適化を有効にするとイメージが変更され、デバッグ情報が不適 切になる可能性があるため、分岐の最適化は標準の設定では無効になっ ています。分岐の最適化を有効にすると、デバッグ情報の修正は行われ ません。 分岐のインライン化の制御に関する詳細については、 「分岐のインライン 化」(P. 3-24)を参照して下さい。 --tailreorder 可能であれば Tail の呼び出しセクションをターゲットの直前に移動し、 セクションの終わりにある分岐命令を最適化します。Tail の呼び出しセ クションとは、セクションの終わりに分岐命令を含むセクションです。 分岐には、セクションの先頭に関数をターゲットとする再配置が含まれ ている必要があります。このオプションには幾つか制限があり、リンカ には以下の制限があります。 • Tail の呼び出しのターゲットごとに 1 つの Tail の呼び出しセク ションしか移動できません。 • Tail の呼び出しセクションをその実行領域外に移動できません。 • Tail の呼び出しセクションをインラインベニアの前には移動しま せん。 Tail の呼び出しセクションの処理の詳細については、 「分岐のインライン 化」(P. 3-24)を参照して下さい。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-27 リンカのコマンド構文 --keep section-id 未使用セクションの削除で削除されないようにする入力セクションを指 定します(「イメージのメモリマップの指定」(P. 3-5)参照)。 すべての形式の section-id 引数には、ワイルドカード * と ? を含めるこ とができます。コマンドラインでは --keep オプションを複数指定でき ます。 section-id には以下のいずれかを指定します。 symbol 未使用セクションの削除中に、symbol を定義している入力セク ションを保持することを指定します。symbol が複数定義されて いる場合は、armlink からエラーメッセージが生成されます。 例えば、--keep int_handler を使用できます。 _handler で終わるシンボルを定義するすべてのセクションを 保持するには、--keep *_handler を使用します。 object(section) 未使用セクションの削除中に、object の section を保持するこ とを指定します。例えば、vectors.o オブジェクトの vect セク ションを保持するには、以下のオプションを使用します。 --keep vectors.o(vect) vectors.o オブジェクトのセクションで、セクション名の先頭 3 文字が vec のセクションをすべて保持するには、以下のオプ ションを使用します。 --keep vectors.o(vec*) object 未使用セクションの削除中に、object の 1 つの入力セクショ ンを保持することを指定します。この短縮形を使用した場合 object に複数の入力セクションが存在すると、armlink からエ ラーメッセージが生成されます。 例えば、--keep dspdata.o を使用できます。 dsp で始まる名前の各オブジェクトで、それぞれ 1 つの入力セ クションを保持するには、--keep dsp*.o を使用します。 --locals 実行可能イメージの生成時に、ローカルシンボルを出力シンボルテーブ ルに追加することをリンカに指示します。これが標準の設定です。 --no_locals 実行可能イメージの生成時に、ローカルシンボルを出力シンボルテーブ ルに追加しないことをリンカに指示します。この最適化処理は、出力シ ンボルテーブルのサイズを小さくするときに便利です。 --fini symbol 終了処理コードのエントリポイントの定義に使用するシンボル名を指定 します。実行可能ファイルまたは共有オブジェクトをアンロードすると きに、動的リンカによってこのコードが実行されます。 「第 6 章 System V の共有ライブラリ」を参照して下さい。 詳細については、 2-28 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 2.2.8 ベニア生成の制御 ベニア生成を制御するには、以下のオプションを使用します。 --no_inlineveneer インラインベニアを生成しないようにして、リンカによるセクションの 配置方法を制御しやすくします。 --no_veneershare リンカでベニアが共有されないようにします。ベニアの共有により、イ メージサイズを大幅に縮小できる場合があります。 これらの 2 つのオプションの詳細については、 「ベニアの生成」 (P. 3-21)を参照して下 さい。 2.2.9 バイトアドレシングモードの指定 バイトアドレシングモードを制御するには、以下のオプションを使用します。 ARMv6 バイトインバリアントアドレシングビッグエンディアンモード を指定します。 --be8 モードです。リンカでは、命令のエンディアン方式を逆にして、ビッグ エンディアン方式でコンパイルおよびアセンブルされた入力オブジェ クトにリトルエンディアンコードとビッグエンディアンデータを提供 します。 バイトインバリアントアドレシングモードは、ARMv6 以上をサポートす る ARM プロセッサでのみ使用できます。 --be32 従来のワードインバリアントアドレシングビッグエンディアンモードを 指定します。これは、ARMv6 より前のビッグエンディアンイメージと同 一です。このオプションを指定すると、ビッグエンディアンコードとビッ クエンディアンデータが生成されます。 ワードインバリアントアドレシングモードは、ARMv6 より前のすべての ビッグエンディアンイメージの標準設定のモードです。 エンディアンのサポートの詳細については以下を参照して下さい。 • RealView Compilation Tools v3.0 Developer Guide の ARMv6 サポートの説明 • ARM DUI 0206GJ ARM アーキテクチャリファレンスマニュアル Copyright © 2002-2006 ARM Limited. All rights reserved. 2-29 リンカのコマンド構文 2.2.10 イメージ関連の情報の生成 イメージに関する情報の抽出および表示方法を制御するには、以下のオプションを使 用します。 --callgraph 関数のスタティックコールグラフを HTML 形式で作成します。コールグ ラフは、イメージ内のすべての関数の定義および参照情報を提供します。 注 リンカで関数のスタックサイズを計算する場合は、すべてのアセンブラ ファイルに PROC/ENDP ディレクティブおよび FRAME PUSH/POP ディレク ティブが含まれている必要があります。 各関数 func について、リンカによって以下の情報が示されます。 • 関数がコンパイルされるときのプロセッサの状態(ARM または Thumb) • func を呼び出す一連の関数 • func によって呼び出される一連の関数 • func のアドレスがイメージ内で使用される回数 また、コールグラフは以下のような関数を識別します。 • インターワークベニア経由で呼び出される関数 • イメージ外で定義された関数 • 未定義の状態が可能な関数(weak 型の参照) また、スタティックコールグラフでは、スタックの使用状況に関する以 下のような情報も提供されます。 • 各関数によって使用されるスタックフレームのサイズ • 任意の呼び出しシーケンス(関数呼び出し非環式チェイン)を介 して関数で使用されるスタックの最大サイズ サイクルがある場合、またはリンカによって呼び出しチェイン内にス タックサイズの情報がない関数が検出された場合、スタックの使用状況 に + Unknown が追加され、スタックの使用状況が不明である理由が追加 されます。 関数のデバッグフレーム情報がない場合は、リンカによって不明なス タックフレームの情報がレポートされます。 間接的な関数については、どの関数によって間接的な呼び出しが行わ れたかを、リンカで確実に判断することはできません。このことは、呼 び出しチェインの最大のスタック使用量の計算に影響する場合があり ます。 2-30 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 アセンブリ言語コードでフレームディレクティブを使用して、コードで スタックを使用する方法を記述します。これらのディレクティブを使用 すると、デバッガのデバッグフレーム情報は確実に存在し、スタック展 開またはプロファイリングが実行されます。 ス タ ッ ク 使 用 量 が 決 定 さ れ る 方 法 の 詳 細 に つ い て は、RealView Compilation Tools v3.0 Assembler Guide のディレクティブ参照について 説明した章を参照して下さい。 --feedback file 次にファイルをコンパイルするときのため、未使用の関数についてコン パイラに通知するフィードバックファイルを生成します。 次にファイルをコンパイルするとき、コンパイラオプション --feedback file を設定して、使用するフィードバックファイルを指定します。未使 用の関数は、関数自体のセクション内に配置され、後でリンカによって 削除できるようになっています。フィードバックファイルの使用方法の 詳細については、 「リンカのフィードバック」 (P. 3-15)を参照して下さい。 --info topics 指定されたトピックに関する情報を出力します。topics は、トピックキー ワードのコンマ区切りのリストを示します。トピックキーワードには以 下のいずれかを使用できます。 common イメージから削除されたすべての共通セクションが一覧表示 されます。このオプションを使用すると、--info common,totals を指定したことになります。 debug --remove を使用したことによってイメージから削除された、 すべての削除された入力デバッグセクションが一覧表示され ます。このオプションを使用すると、--info debug,totals を 指定したことになります。 inline --inline を使用したことによってリンカによりインライン化 された、すべての関数の詳細およびインラインの総数が表示 されます。分岐のインライン化に関する詳細については、 「分 岐のインライン化」(P. 3-24)を参照して下さい。 libraries リンクステージに対して自動的に選択されたすべてのライブ ラリの完全パス名が出力されます。 このオプションを修飾子 --info_lib_prefix と共に使用する と、特定のライブラリに関する情報を表示できます。例えば、 以下のオプションを使用すると、リンカによって使用される 浮動小数点ライブラリを識別できます。 --info libraries --info_lib_prefix=f ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-31 リンカのコマンド構文 sizes イメージ内の入力オブジェクトおよびライブラリのメンバご とに、コードとデータ(RO データ、RW データ、ZI データ、 およびデバッグデータ)のサイズが一覧表示されます。この オプションを使用すると、--info sizes,totals を指定したこ とになります。 tailreorder --tailreorder を使用したことによって、ターゲットの上に移 動したすべての Tail の呼び出しセクションの詳細が表示され ます。Tail の呼び出しセクションの処理の詳細については、 「分 岐のインライン化」(P. 3-24)を参照して下さい。 totals 入力オブジェクトとライブラリの、コードとデータ(RO デー タ、RW データ、ZI データ、およびデバッグデータ)のサイ ズの合計が表示されます。 veneers リンカによって生成されるベニアの詳細が表示されます。ベ ニアの詳細については、 「ベニアの生成」 (P. 3-21)を参照して 下さい。 unused --remove を使用したことによってイメージから削除された、 すべての未使用のセクションが一覧表示されます。 exceptions 例外テーブルの生成と最適化に関する詳細が表示されます。 --info sizes,totals を使用した場合の出力には、常に入力オブジェクト とライブラリの合計にパッドする値が含まれます。 RW データ圧縮(標準の設定)を使用している場合、または --datacompressor id オプションを使用してコンプレッサを指定した場 合、--info sizes,totals からの出力には Grand Totals の下に、イメージ の実際のサイズを示すエントリが表示されます。 注 リスト内のキーワードの間にはスペースを入れないで下さい。例えば、 「--info sizes,totals」 と入力することができます が、 「--info sizes, totals」 と入力することはできません。 この情報の使用方法の詳細については、「イメージに関する情報の取得」 (P. 3-35)を参照して下さい。 2-32 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 --mangled 診断メッセージと、--xref、--xreffrom、--xrefto、および --symbols オ プションによって生成されたリストに符号化された C++ シンボル名を 表示するようリンカが設定されます。 このオプションを選択した場合、リンカでは C++ シンボル名を符号化し ます。シンボル名は、オブジェクトのシンボルテーブルに表示されると きと同じように表示されます。 --unmangled 診断メッセージと、--xref、--xreffrom、--xrefto、および --symbols オ プションによって生成されたリストに符号化されていない C++ シンボ ル名を表示するようリンカが設定されます。 このオプションを選択した場合、リンカでは C++ シンボル名を符号化せ ず、C++ シンボル名はソースコードに表示されるときと同じように表示 されます。これが標準の設定です。 --map イメージマップを作成します。このマップには、各ロード領域、実行領 域、およびイメージの入力セクション(リンカによって生成された入力 セクションを含む)のアドレスとサイズが含まれます。 --symbols リンク手順で使用される各ローカルシンボルとグローバルシンボル、お よびその値を一覧表示します。 注 これにはマッピングシンボルは含まれません。出力結果にマッピングシ ンボルを含めるには、--list_mapping_symbols を使用して下さい。 --list_mapping_symbols --symbols の出力結果にマッピングシンボルが含まれます。 シンボルテーブルでは、マッピングシンボルは ARM コード、Thumb コー ド、およびデータの間のフラグの遷移に使用されます(詳細については、 ELF for the ARM Architecture [AAELF]を参照して下さい)。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-33 リンカのコマンド構文 --symdefs file 出力イメージから、グローバルシンボル定義を含むファイルを作成し ます。 標準の設定では、すべてのグローバルシンボルが symdefs ファイルに書 き込まれます。file という symdefs ファイルが既に存在する場合、リン カはこのファイルに記述されているシンボルの出力を制限します。 注 この処理が必要ない場合は、リンク手順の前にすべての既存の symdefs ファイルを削除して下さい。 file にパス情報が指定されていない場合、リンカは出力イメージが書き 込まれるディレクトリ内でファイルを検索します。ファイルが検出され ない場合は、そのディレクトリ内に作成されます。 シンボル定義ファイルは、他のイメージをリンクするときの入力として 「別のイメージに含まれるシンボルへの 使用できます。詳細については、 アクセス」(P. 4-8)を参照して下さい。 --xref 入力セクション間のすべての相互参照を一覧表示します。 --xrefdbg 入力デバッグセクション間のすべての相互参照を一覧表示します。 --xreffrom object(section) object 内の入力セクション(section)から別の入力セクションへの相互 参照を一覧表示します。この一覧は --xref を使用することによって得ら れる一覧のサブセットであり、特定の入力セクションからの参照を調べ るときに便利です。このオプションを複数使用して、複数の入力セクショ ンからの参照の一覧を表示できます。 --xrefto object(section) 他の入力セクションから object 内の入力セクション(section)への相 互参照を一覧表示します。この一覧は --xref を使用することによって得 られる一覧のサブセットであり、特定の入力セクションへの参照を調べ るときに便利です。このオプションを複数使用して、複数の入力セクショ ンへの参照の一覧を表示できます。 2-34 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 2.2.11 リンカの診断の制御 リンカによる診断情報の生成方法を制御するには、以下のオプションを使用します。 --diag_style arm|ide|gnu 警告メッセージやエラーメッセージの形式を変更します。--diag_style arm が標準の設定です。--diag_style gnu を指定すると、gcc から返され る形式になり、--diag_style ide を指定すると Microsoft Visual Studio か ら返される形式になります。 標準の設定は arm です。例えば、標準の設定では、以下のようになります。 "sct.txt", line 15 (column 14): Warning: L6314W: No section matches pattern *(RW). Finished: 0 information, 1 warning and 0 error messages. --diag_style ide を指定すると、以下のようになります。 sct.txt(15, 14): warning: L6314: No section matches pattern *(RW). armlink: Finished: 0 information, 1 warning and 0 error messages. --diag_style gnu を指定すると、以下のようになります。 sct.txt:15:14: Warning: L6314W: No section matches pattern *(RW). Finished: 0 information, 1 warning and 0 error messages. --diag_suppress taglist 指定されたタグを含むすべての診断メッセージを無効にします。 このオプションには、非表示にする必要がある診断メッセージの番号を コンマで区切ったリストを指定する必要があります。例えば、番号 L6314W と L6305W の警告メッセージを非表示にするには、以下のコマンドを使用 します。 armlink --diag_suppress L6314,L6305 ... --diag_warning taglist 指定されたタグを含む診断メッセージが警告メッセージとして表示され るように設定します。このオプションは、エラーメッセージの順位を下 げさせる様な場合などに使用できます。 このオプションには、順位を下げる必要がある診断メッセージの番号を コンマで区切ったリストを指定する必要があります。 --errors file 診断結果の出力を標準のエラーストリームから file に転送します。 指定されたファイルは、リンクステージの開始時に作成されます。同じ 名前のファイル既に存在する場合、そのファイルは削除されます。 file にパス情報が指定されていない場合、現在のディレクトリにファイ ルが作成されます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-35 リンカのコマンド構文 --list file --info、--map、--symbols、--xref、--xreffrom、および --xrefto コマン ドの出力から file に診断結果の出力を転送します。 指定されたファイルは、診断結果の出力時に作成されます。同じ名前の ファイルが既に存在する場合、そのファイルは上書きされます。ただし、 診断結果が出力されない場合はファイルが作成されません。この場合、 同じ名前の既存のファイルの内容は変更されません。 file にパス情報が指定されていない場合、出力ディレクトリ(出力イ メージが書き込まれるディレクトリ)内にファイルが作成されます。 --verbose インクルードされるオブジェクト、オブジェクト取得元のライブラリな ど、リンク操作についての詳細情報が出力されます。通常、この出力は 非常に長いため、このコマンドを --errors file コマンドと組み合わせ て使用して、情報を file に転送することができます。 --verbose を使用すると、診断結果が stderr に出力されます。 診断メッセージの接頭文字 RVCT ツールは、表 2-1 に示す識別文字を自動的に診断メッセージに挿入します。これ らの接頭文字を使用することにより、RVCT ツールは重複したメッセージ範囲を使用で きます。 表 2-1 診断メッセージの識別 接頭文字 RVCT ツール C armcc A armasm L armlink または armar Q fromelf 以下の規則が適用されます。 • すべての RVCT ツールは、接頭文字が含まれていないメッセージ番号の影響を受 けます。 • 接頭文字が含まれたメッセージ番号は、その接頭文字に該当するツールのみに作 用します。 • ツールは、一致しない接頭文字が含まれているメッセージの影響は受けません。 したがって、--diag_error、--diag_remark、および --diag_warning を指定したり、メッ セージを非表示にしたりする場合は、以下のようにリンカ接頭文字 L を使用できます。 armlink --diag_suppress L6314,L6305 ... 2-36 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ リンカのコマンド構文 2.2.12 via ファイルの使用 リンカのコマンドラインに追加する引数を含む via ファイルを指定するには、以下のオ プションを使用します。 --via file file から追加の入力ファイル名およびリンカのオプションのリストが読 み出されます。 リンカのコマンドラインで複数の --via オプションを入力できます。ま た、via ファイル内に --via オプションを含めることもできます。 via ファイルの記述方法の詳細については、RealView Compilation Tools v3.0 Compiler and Libraries Guide を参照して下さい。 2.2.13 その他 標準の設定では、リンカで実行領域およびロード領域が 4 バイト境界で整列されると 想定されています。これにより、リンカはイメージに挿入するパディングを最小限に 抑えることができます。 --no_legacyalign オプションを使用すると、パディングが挿入され標準境界調整が使 用されるようにリンカが設定されます。ELF の仕様に厳密に適合するには、このオプ ションを使用して下さい(詳細については、 「セクションの配置」(P. 3-8)を参照して 下さい)。 2.2.14 従来のオブジェクトとの互換性の制御 RVCT v3.0 の ABI は、ADS v1.2 および RVCT v1.2 の ABI とは異なります。そのため、 従来の ADS v1.2 と RVCT v1.2 のオブジェクトおよびライブラリは、RVCT v3.0 と直接 の互換性がありません。--apcs /adsabi コンパイラオプションを使用すると、制限付き の互換性が提供されます。 詳細については、RealView Compilation Tools v3.0 Compiler and Libraries Guide の ARM コ ンパイラの仕様に関する章、および RealView Compilation Tools v3.0 Essentials Guide の従 来のオブジェクトとの互換性に関するセクションを参照して下さい。 注 今後のリリー --apcs /adsabi コンパイラオプションのサポートは現在制限されており、 スで廃止される予定です。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 2-37 リンカのコマンド構文 2-38 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 第3章 基本リンカ機能の使用 本章では、RealView® Compilation Tools (RVCT)付属の ARM® リンカ armlink の基本機 能について説明します。本章は以下のセクションから構成されています。 • イメージ構造の指定(P. 3-2) • • • • • セクションの配置(P. 3-8) 最適化と修正(P. 3-11) コマンドラインオプションを使用した単純イメージの作成(P. 3-28) コマンドラインオプションを使用した C++ 例外の処理(P. 3-34) イメージに関する情報の取得(P. 3-35) リンカのより高度な機能については、以下のセクションを参照して下さい。 • シンボルへのアクセス方法 - 第 4 章 イメージのシンボルへのアクセス • ARM DUI 0206GJ スキャッタローディング - 第 5 章 スキャッタローディング記述ファイルの使用 Copyright © 2002-2006 ARM Limited. All rights reserved. 3-1 基本リンカ機能の使用 3.1 イメージ構造の指定 イメージの構造は以下によって定義されます。 • イメージを構成する領域と出力セクションの数 • イメージがロードされるときの、上記領域とセクションのメモリ内における位置 • イメージが実行されるときの、上記領域とセクションのメモリ内における位置 このセクションでは、以下の内容について説明します。 • オブジェクトとイメージのビルディングブロック • イメージのロードビューと実行ビュー(P. 3-3) • • 3.1.1 イメージのメモリマップの指定(P. 3-5) イメージのエントリポイント(P. 3-6) オブジェクトとイメージのビルディングブロック 実行可能ファイルに格納される 1 つのイメージは、イメージ、領域、出力セクション、 および入力セクションの階層から構成されています。 • 1 つのイメージは、1 つ以上の領域から構成されます。各領域は 1 つ以上の出力 セクションから構成されます。 • 各出力セクションは 1 つ以上の入力セクションから構成されます。 • 入力セクションは、オブジェクトファイル内のコードおよびデータ情報です。 P. 3-2 図 3-1 は、領域、出力セクション、および入力セクションの関係を示しています。 Input section 1.1.1 Input section 1.1.2 Output section 1.1 Region 1 Output section 1.2 Output section 1.3 Input section 1.2.1 Input section 1.3.1 Input section 1.3.2 Region 2 Output section 2.1 Input section 2.1.1 Input section 2.1.2 Input section 2.1.2 Memory 図 3-1 イメージのビルディングブロック 3-2 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 図 3-1 は、イメージを構成するビルディングブロックを示しています。 入力セクション 入力セクションには、コードや初期化されたデータが保持されていたり、 初期化されていないメモリ部分やイメージ実行前にゼロにする必要のあ るメモリ部分の情報が記述されていたりします。入力セクションには、 RO、RW、ZI のいずれかの属性を設定できます。armlink はこれら 3 つの属 性を使用して入力セクションをグループ化し、出力セクションまたは出 力領域と呼ばれる大きなビルディングブロックを作成します。 出力セクション 1 つの出力セクションは、RO、RW、ZI のうちで同じ属性を持った、連続す る一連の入力セクションから構成されます。出力セクションは、それを 構成する入力セクションと同じ属性を持ちます。出力セクションでは、 「セクションの配置」 (P. 3-8)で説明されている規則に基づいて入力セク ションがソートされます。 1 つの領域は、1 ~ 3 個の連続する出力セクションから構成されます。領 域内の出力セクションは、属性でソートされます。最初に RO 出力セク ション、次に RW 出力セクション、最後に ZI 出力セクションが配置され ます。通常、ROM、RAM、ペリフェラルなどの物理メモリデバイスに マップされます。 領域 3.1.2 イメージのロードビューと実行ビュー イメージの領域は、ロード時にシステムのメモリマップ内に配置されます。イメージ を実行するには、その前にいくつかの領域を実行アドレスへ移動し、ZI 属性を持つ出 力セクションを作成しなければならない場合があります。例えば、初期化された RW データを、ROM 内のロードアドレスから RAM 内の実行アドレスにコピーしなければ ならない場合があります。 イメージのメモリマップには、以下の 2 つの異なるビューがあります(図 3-2 参照)。 ARM DUI 0206GJ ロードビュー このビューは、イメージがメモリにロードされるときの各領域と 各セクションのアドレス、つまり、イメージの実行が開始される 前の位置を示します。 実行ビュー このビューは、イメージの実行中における各領域と各セクション のアドレスを示します。 Copyright © 2002-2006 ARM Limited. All rights reserved. 3-3 基本リンカ機能の使用 Load view 0x0FFFF Memory initialized to zero RAM 0x0A000 0x08000 ROM RW section Execution view ZI section RW section 0x06000 RO section 0x00000 RO section 図 3-2 ロードメモリマップと実行メモリマップ 表 3-1 は、ロードビューと実行ビューを比較説明しています。 表 3-1 ロードビューと実行ビューの比較 ロードビュー 説明 実行ビュー 説明 ロードアドレス イメージの実行開始前まで、そのイ メージ内のセクションまたは領域が ロードされているメモリ内のアドレ ス。セクションまたは非ルート領域 のロードアドレスは、実行アドレス と異なっていても構いません。 実行アドレス イ メ ー ジ の 実 行 中 に、そ の イ メージ内のセクションまたは領 域が位置するアドレス。 ロード領域 ロードアドレス空間内の領域。 実行領域 実行アドレス空間内の領域。 3-4 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 3.1.3 イメージのメモリマップの指定 1 つのイメージを構成する領域と出力セクションの数に制限はありません。イメージを 構成する領域には、その数にかかわらず、異なるロードアドレスと実行アドレスを割 り当てることができます。イメージのメモリマップを作成するには、以下に関する情 報を armlink に渡す必要があります。 グループ化 入力セクションを出力セクションと領域にグループ化する方法 配置 メモリマップ内におけるイメージ領域の位置 イメージのメモリマップの複雑度に応じて、この情報は以下の 2 つの方法で armlink に 渡すことができます。 コマンドラインオプションを使用する イメージ内のロード領域が 1 つか 2 つで、実行領域が最高でも 3 つしか ないような単純な場合は、以下のオプションを使用できます。 • --ro-base • --rw-base • --ropi • --rwpi • --split • --rosplit 単純イメージについては、上記のオプションを使用した簡単な表記に よって、スキャッタローディングの記述と同じ設定が可能です。詳細に ついては、 「コマンドラインオプションを使用した単純イメージの作成」 (P. 3-28)を参照して下さい。 スキャッタローディング記述ファイルを使用する イメージコンポーネントのグループ化と位置を厳密に制御する必要があ る複雑な場合は、スキャッタローディング記述ファイルを使用します。 スキャッタローディング記述ファイルを使用するには、コマンドライン 「第 5 章 スキャッ で --scatter filename と指定します。詳細については、 タローディング記述ファイルの使用」を参照して下さい。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-5 基本リンカ機能の使用 3.1.4 イメージのエントリポイント イメージ内のエントリポイントは、プログラムの実行開始位置です。エントリポイン トには以下の 2 つの種類があります。 初期エントリポイント イメージの初期エントリポイントは 1 つの値で表され、ELF ヘッダファ イルに格納されています。オペレーティングシステムまたはブートロー ダによって RAM にロードされるプログラムの場合、ローダはイメージ 内の初期エントリポイントに制御を渡すことによって、イメージの実行 を開始します。 1 つのイメージ内で使用できる初期エントリポイントは 1 つだけです。初 期エントリポイントとして、ENTRY ディレクティブによって設定されたエ ントリポイントの 1 つを使用できますが、必ずしもそうする必要はあり ません。 ENTRY ディレクティブによって設定されたエントリポイント ENTRY ディレクティブを使用してアセンブリ言語ソース内に設定されて いるエントリポイントです。組み込みシステムの場合、一般的に、この ディレクティブはプロセッサ例外ベクタ(RESET、IRQ、FIQ など)経由で 開始されるコードをマークするために使用されます。 ENTRY ディレクティブを使用すると、1 つのイメージ内に複数のエントリ ポイントを指定できます。このディレクティブでは、ENTRY キーワードを 使用して、リンカによって未使用セクションが削除されるときに残して おく出力コードセクションをマークすることにより、そのセクションを 残しておくことができます。 C や C++ で記述されたプログラムの場合、C ライブラリの __main() 関数 もエントリポイントとなります。 ENTRY ディレクティブの詳細については、RealView Compilation Tools v3.0 Assembler Guide を参照して下さい。 組み込みイメージがローダによって使用される場合には、そのイメージ のヘッダ内に 1 つの初期エントリポイントが指定されている必要があ 「初期エントリポイントの指定」を参照して下 ります。詳細については、 さい。 3-6 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 初期エントリポイントの指定 初期エントリポイントは --entry リンカオプションを使用して指定できます。--entry オプションを指定できるのは 1 度だけです。詳細については、「armlink のコマンド構 文」(P. 2-10)を参照して下さい。 アドレスのゼロに ROM が配置される組み込みアプリケーションの場合には、--entry 0x0 を 使 用 し ま す(ま たは上位ベクタを使用する CPU では、オプションとして 0xFFFF0000 を使用します) 。 初期エントリポイントは、以下の条件を満たしている必要があります。 • イメージのエントリポイントが常に実行領域内に存在していること • 実行領域が非オーバーレイ実行領域で、かつルート実行領域である(ロードアド レスと実行アドレスが同じである)こと --entry オプションを使用せずに初期エントリポイントを指定する場合は、以下のよう になります。 • 入力オブジェクトに、ENTRY ディレクティブによって設定された 1 つのエントリ ポイントしか含まれていない場合には、リンカはそのエントリポイントをイメー ジの初期エントリポイントとして使用します。 • リンカは以下のいずれかの場合に、初期エントリポイントが含まれていないイ メージを生成します。 — ENTRY ディレクティブによって複数のエントリポイントが指定されている 場合 — ENTRY ディレクティブによって指定されているエントリポイントが存在し ない場合 どちらの場合にも、リンカによって以下の警告が生成されます。 L6305W: Image does not have an entry point.(Not specified or not set due to multiple choices) この警告が生成されないようにするには、--entry を使用して固有のエントリポ イントを指定します。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-7 基本リンカ機能の使用 3.2 セクションの配置 リンカは、領域内のすべての入力セクションを属性でソートします。同一属性を持つ 入力セクションは、領域内で連続して配置され、1 つのブロックを形成します。 各入力セクションのベースアドレスは、リンカによって定義されるソート順序によっ て決定され、それを含む出力セクション内でも正しく整列されます。 通常、イメージを生成するとき、リンカは以下の順序で入力セクションをソートし ます。 1. 属性 2. 入力セクションの名前 3. 入力リスト内における各セクションの位置(FIRST または LAST によってオーバー ライドされている場合を除く、「FIRST と LAST を使用したセクションの配置」 (P. 3-9)参照。) 実行領域に 4MB を超える Thumb® コードまたは 32MB を超える ARM コードが含まれ る場合、リンカは、ソート順序を変更して、長分岐ベニアの数を最小限まで削減する 場合があります。 標準の設定では、リンカによって作成されるイメージは、RO と RW の属性(オプショ ンで ZI)を持つ出力セクションから構成されます。メモリ管理ハードウェアを搭載し たシステムでは、ランタイム時に RO 出力セクションを保護できます。また、RO セク ションはターゲットの ROM に配置することも可能です。 このセクションでは、以下の内容について説明します。 • 属性による入力セクションの順序付け(P. 3-9) • FIRST と LAST を使用したセクションの配置(P. 3-9) • セクションの整列(P. 3-10) Thumb コードを含む実行領域の順序付け(P. 3-10) • 3-8 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 3.2.1 属性による入力セクションの順序付け イメージ部分は、数を最小限に抑えた連続領域にまとめられます。armlink は、以下の ように属性による入力セクションの順序付けを行います。 1. 読み出し専用コード 2. 読み出し専用データ 3. 読み出し - 書き込みコード 4. 他の初期化データ 5. ゼロで初期化された(未初期化)データ 同一属性を持つ入力セクションは、名前によって順序付けされます。名前では、大文 字と小文字が区別され、ASCII 文字照合シーケンスを使用してアルファベット順で比較 されます。 同一の属性と名前を持つ入力セクションは、入力リスト内における相対位置によって 順序付けられます。 したがって、ライブラリからインクルードされる、同じ属性と名前を持つ入力セクショ ンの位置は予測不能です。厳密な位置設定を行う必要がある場合には、モジュールを 手動で抽出して、入力リストに組み込むことができます。 3.2.2 FIRST と LAST を使用したセクションの配置 領域内では、すべての RO コード入力セクションが連続して配置され、1 つの RO 出力 セクションが形成されます。この RO 出力セクションは、すべての RW 入力セクショ ンを含む出力セクションよりも前に配置されます。 スキャッタローディングを使用しない場合には、リンカオプション --first および --last を使用して入力セクションを配置します。 スキャッタローディングを使用するとき、配置順序が重要な場合には、スキャッタロー ディング記述ファイル内で属性 FIRST および LAST を使用し、実行領域内の最初と最後 の入力セクションをマークします。 ただし、FIRST および LAST 属性の用法は、基本属性ソート順序に違反しないようにす る必要があります。つまり、ある入力セクションは、それを含む出力セクションが実 行領域内の最初(または最後)の出力セクションである場合に、その領域内の最初(ま たは最後)に配置できます。例えば、RO 入力セクションを含む実行領域内の FIRST 入 力セクションは、RO 入力セクションである必要があります。同様に、実行領域に ZI 入力セクションが含まれている場合には、LAST 入力セクションは ZI 入力セクションで ある必要があります。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-9 基本リンカ機能の使用 3.2.3 セクションの整列 入力セクションの順序付けが行われた後、armlink はベースアドレスが固定される前に 必要に応じてパディングを挿入し、各入力セクションをその境界調整の倍数になるア ドレスから開始させます。 ARM リンカでは、入力セクションの最大の境界調整に関係なく、ELF プログラムの ヘッダおよび出力セクションを 4 バイト境界で整列させることができます。これによ り、armlink は、イメージに挿入するパディングを最小限に抑えることができます。 ELF の仕様に厳密に適合する必要がある場合は、 --no_legacyalign オプションを使用し ます。ELF の使用に準拠するためにパディングが挿入されることがありますが、リン カにより、0 mod Max(入力セクションの境界調整 ) ではないベースアドレスでエラーが発生 します。 ALIGN を使用して境界調整を拡張する(通常は 4 バイト境界で整列されるものを 8 バイ ト境界で整列させる)ことは可能ですが、標準境界調整を縮小する(通常は 4 バイト 境界で整列されるものを 2 バイト境界で整列させる)ことはできません。 入力セクションの境界調整は、例 3-1 に示すように、以下の属性を使用してアセンブリ コード内で指定できます。 ALIGN この属性はアセンブリ言語の中で AREA ディレクティブに使用します。こ の場合の入力セクションアドレスは、2(align 属性の値 ) の倍数となります。 例 3-1 アセンブリコードにおける ALIGN 属性の使用 AREA LDR_LABEL, CODE, READONLY, ALIGN=3 ; align on eight-byte boundary 詳細については、RealView Compilation Tools v3.0 Assembler Guide のディレクティブ参照 について説明した章にある ALIGN の説明を参照して下さい。 3.2.4 Thumb コードを含む実行領域の順序付け Thumb 分岐の範囲は 4MB です。実行領域に 4MB を超える Thumb コードが含まれてい ると、armlink は、平均的に同じコールの深さにあるセクションの順序付けを行い、最 もよく呼び出されるセクションを中央に配置します。これにより、生成されるベニア の数を最小限に抑えることができます(「ベニアの生成」(P. 3-21)参照)。 3-10 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 3.3 最適化と修正 このセクションでは、以下の内容について説明します。 • 共通デバッグセクションの削除 • 共通グループまたは共通セクションの削除 • 未使用セクションの削除(P. 3-12) • • • • • • 3.3.1 未使用関数の削除(P. 3-13) リンカのフィードバック(P. 3-15) RW データ圧縮(P. 3-18) ベニアの生成(P. 3-21) オーバーレイ実行領域へのベニアの再利用(P. 3-23) 分岐のインライン化(P. 3-24) 共通デバッグセクションの削除 DWARF 2 では、コンパイラとアセンブラは、コンパイル単位のソースファイルごとに デバッグセクション群を生成します。armlink は、特定のソースファイルのデバッグセ クションの複数のコピーを検出し、最終イメージ内に残す 1 つのコピーを除き、残り すべてのデバッグセクションを破棄します。この結果、イメージのデバッグサイズが 大幅に縮小されます。 DWARF 3 では、共通デバッグセクションは共通グループに配置されます。 3.3.2 共通グループまたは共通セクションの削除 C++ ソース内でインライン関数またはテンプレートが使用されている場合、ARM コン パイラは、オブジェクトがそれぞれ必要とするインライン関数とテンプレート関数の アウトオブラインコピーを保持するように、リンク用の完全なオブジェクトを生成し ます。このような関数が共通ヘッダファイルで宣言されている場合、関数は、その後 リンクする各オブジェクト内で何度も定義される可能性があります。コンパイラは、重 複を回避するために、これらの関数を共通コードセクションまたは共通グループの 個々のインスタンスにコンパイルします。 共通コードセクションまたは共通グループの個々のインスタンスが同一でない場合も あります。例えば、コピーの一部は、異なる(ただし互換性のある)ビルドオプショ ン、最適化、またはデバッグオプションを使用してビルドされたライブラリ内で検出 される場合があります。 コピーが同一でない場合、armlink は、入力オブジェクトの属性に基づき、各共通コー ドセクションまたは各共通グループの最も可用性の高いバリアントを保持します。そ れ以外のバリアントは破棄されます。 コピーが同一である場合、armlink は、最初に検出したセクションまたはグループを保 持します。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-11 基本リンカ機能の使用 この最適化は、以下のリンカオプションを使用して制御できます。 • --bestdebug オプションを使用すると、最大の Comdat グループを使用できます (最適なデバッグビューが提供される可能性が高くなります)。 • --no_bestdebug オプションを使用すると、最小の Comdat グループを使用できま す(コードサイズを最も小さくできる可能性が高くなります)。これが標準の設 定です。ほとんどの場合、--bestdebug を使用する必要があることはありません。 --no_bestdebug が標準なので、-g を使用してコンパイル中にデバッグテーブルを 生成するかどうかに関係なく、最終イメージは同じになります。 詳細については、RealView Compilation Tools v3.0 Compiler and Libraries Guide の ARM コンパイラの使用方法に関する章の「デバッグ情報の生成」を参照して下 さい。 3.3.3 未使用セクションの削除 未使用セクションの削除によって、一度も実行されないコード、またはそのコードに よって参照されないデータが最終イメージから削除されます。この最適化は、--remove、 --no_remove、--first、--last、および --keep のリンカオプションを使用して制御でき ます。--info unused リンカオプションを使用すると、削除された未使用セクションの リストを生成するようリンカに指示できます。 未使用セクションの削除は、結果としてすべてのセクションが削除されるような場合 には使用されません。 入力セクションは、以下の場合に最終イメージに保持されます。 • エントリポイントが含まれている場合 • エントリポイントを含む入力セクションから非 weak 型の参照によって、直接的 または間接的に参照される場合 • --first オプションまたは --last オプション(あるいはこれと同じ意味を持つス キャッタローディングの記述)を使用して、最初または最後の入力セクションと して指定されている場合 • --keep オプションによって削除不可としてマークされている場合 注 未使用セクションの削除は、共通グループだけでなく、すべてのグループに対して行 うことができます。 3-12 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 3.3.4 未使用関数の削除 仮想関数の削除(VFE)は、C++ コードから生成されたイメージの ROM サイズを縮小 するために未使用セクションの削除を改良したものです。この最適化を使用すると、未 使用の仮想関数および RTTI オブジェクトをコードから削除できます。 関数が関数独自のセクションにコンパイルされる場合、VFE は未使用セクションの削 除と同じ意味になります(「未使用セクションの削除」(P. 3-12)参照)。ただし、複数 の関数が含まれるセクションについては、すべての関数が未使用の場合にのみ削除さ れます。リンカは、未使用関数を含むセクション内から、未使用関数を削除すること はできません。 このセクションの残りの部分では、関数が関数独自のセクションにコンパイルされる ことを前提としています。 未使用セクションの削除を使用すると、未使用関数を効率的に C コードから削除でき ます。しかし、C++ アプリケーションでは、未使用セクションや RTTI オブジェクトが ポインタテーブルによって参照されています。つまり、リンカで使用されている削除 アルゴリズムでは、未使用セクションと RTTI オブジェクトを確実に削除することを保 証できません。 VFE は ARM コンパイラとリンカによる連携です。コンパイラが未使用の仮想関数に関 する追加情報をリンカに提供し、リンカがその情報を使用します。コンパイラによる 分析に基づき、リンカは未使用セクションを確実に削除できます。また、この連携に より、リンカは RTTI オブジェクトも削除できます。 注 アセンブラソースファイルは、C++ ライブラリを参照していなければ、VFE の注釈を 必要としません。これは、リンカでは、C++ ライブラリを参照しないオブジェクトファ イルによって仮想関数が呼び出されることはないと想定されているためです。同様に、 古いバージョンの armcc でコンパイルされた C ソースファイルは、C++ ライブラリを 参照していなければ、VFE の対象となり得ます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-13 基本リンカ機能の使用 VFE は以下の 4 つのモードで動作します。 On コマンドラインオプション --vfemode=on を使用すると、リンカは VFE に 対応します。コマンドラインで VFE オプションを指定しない場合、これ が標準のモードです。 このモードでは、リンカは、オブジェクトファイルの内容に基づいて force モードまたは off モードを選択します。 • すべてのオブジェクトファイルが VFE 情報を保持しているか、ま たは C++ ライブラリを参照していない場合、リンカは force モー ドが選択されていると見なして、削除を続行します。 • VFE 情報を保持していないか、または C++ ライブラリを参照して いるオブジェクトファイルがある場合(例えば、以前リリースさ れた ARM ツールを使用してコードがコンパイルされている場 合)、リンカは off モードが選択されていると見なすため、VFE が 自動的にディセーブルされます。この場合に off モードを選択し て VFE をディセーブルすると、VFE 情報を持たないオブジェクト で使用される仮想関数がリンカによって削除されることはありま せん。 Off コマンドラインオプション --vfemode=off を使用すると、armlink はコン パイラが提供する追加情報を無視します。このモードでは、最終イメー ジは VFE に対応していないコンパイルおよびリンクによって生成され るイメージと同じになります。 Force コマンドラインオプション --vfemode=force を使用すると、リンカは VFE に対応し、VFE アルゴリズムを強制的に適用できます。オブジェク トファイルの一部に VFE 情報が含まれていない場合(例えば、以前リ リースされた ARM ツールを使用してコンパイルされている場合)、リン カは削除を続行しますが、エラーが発生する可能性のあることを示す警 告メッセージを生成します。 Force no RTTI コマンドラインオプション --vfemode=force_no_rtti を使用すると、リン カは VFE に対応し、すべての RTTI オブジェクトが強制的に削除されま す。このモードでは、すべての仮想関数は保持されます。 3-14 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 コンパイラは、.arm_vfe という名前で始まるセクションに追加情報を配置します。こ れらのセクションは残りのコードでは参照されないので、VFE に対応していない場合 は無視されます。そのため、このようなセクションによって、最終イメージのサイズ が増加することはありませんが、コンパイラによって生成されるオブジェクトファイ ルのサイズが増加します。 コンパイラが VFE 情報を生成しないようにするには、コンパイラオプション --no_vfe を使用します。ただし、VFE をディセーブルするには、リンカオプション --vfemode=off を使用することをお勧めします。 注 コマンドラインで VFE オプションを指定しない場合は、標準のモード --vfemode=on が 想定されます。 3.3.5 リンカのフィードバック armlink は、次にファイルをコンパイルするときのため、未使用の関数についてコンパ イラに通知するフィードバックを提供します。フィードバックは関数自体のセクショ ン内に配置され、後でリンカによって削除できるようになっています。 --inline の最適化が有効な場合( 「分岐のインライン化」(P. 3-24)参照)、リンカによ りインライン化された関数がフィードバックファイルにも書き込まれます。また、こ れらの関数は関数自体のセクション内にも配置されます。 --feedback file オプションを使用すると、コメントとして各出力ファイル名とその ファイル内で検出された未使用のシンボルを含むフィードバックファイルが生成され ます。以下に例を示します。 ;#<FEEDBACK># ARM Linker, RVCT3.0 [Build num]: Last Updated: Date ;VERSION 0.2 ;FILE dhry_1.o unused_func1 <= USED 0 inlined_func <= LINKER_INLINED ;FILE dhry_2.o unused_func2 <= USED 0 次にソースをコンパイルするときに、コンパイラオプション --feedback file でリンカ によって生成されたフィードバックファイルを指定して使用します。フィードバック ファイルが存在しない場合は、コンパイラによって警告メッセージが生成されます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-15 基本リンカ機能の使用 リンカのフィードバックの例 リンカのフィードバックの動作を確認するには 1. 例 3-2 に示すコードを含む fb.c という名前のファイルを作成します。 例 3-2 フィードバックの例 #include <stdio.h> void legacy() { printf("This is a legacy function, that is no longer used.\n"); } int cubed(int i) { return i*i*i; } void main() { int n = 3; printf("%d cubed = %d\n",n,cubed(n)); } 2. 以下のコマンドラインを実行して、プログラムをコンパイルします(フィード バックファイルが存在しないことを示す警告メッセージは無視します) 。 armcc --asm -c --feedback fb.txt fb.c これにより、通常 cubed() 関数がインライン化されます。また、アセンブラファ イル fb.s とオブジェクトファイル fb.o が作成されます。アセンブラファイルに は、legacy() と cubed() のコードが残っていますが、インライン化により、main から cubed() を呼び出すことはありません。 cubed() のアウトオブラインコピーは、static として宣言されていないため、保 持されています。 3. 以下のコマンドラインを実行して、オブジェクトファイルをリンクし、リンカの フィードバックファイルを作成します。 armlink --info sizes --list fbout1.txt --feedback fb.txt fb.o -o fb.axf リンカによる診断結果がファイル fbout1.txt に出力されます。 注 これらのオプションの詳細については、「イメージ関連の情報の生成」(P. 2-30) および「リンカの診断の制御」 (P. 2-35)を参照して下さい。 3-16 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 リンカのフィードバックファイルは、 (コンパイラで使用されない)コメントと して未使用の関数を含み、かつ legacy() 関数と cubed() 関数のエントリを含んで いるソースファイルを特定します。以下に例を示します。 ;#<FEEDBACK># ARM Linker, RVCT 3.0 [Build num]: Last Updated: Date ;VERSION 0.2 ;FILE fb.o cubed <= USED 0 legacy <= USED 0 このフィードバックファイルは、2 つの関数が使用されていないことを示します。 4. 以下のコマンドラインを実行し、別のフィードバックファイルを使用してコンパ イルとリンクのステージを実行します。 armcc --asm -c --feedback fb.txt fb.c armlink --info sizes --list fbout2.txt fb.o -o fb.axf 5. 2 つの診断ファイル fbout1.txt と fbout2.txt を比較し、イメージのコンポーネ ント(例えば、Code、RO Data、RW Data、ZI Data)のサイズを確認します。Code コンポーネントが小さくなります。 legacy() 関数と cubed() 関数がメインの .text 領 アセンブラファイル fb.s には、 域に存在しません。これらの関数は関数独自の ELF セクションにコンパイルさ れます。そのため、armlink は最終イメージから legacy() 関数と cubed() 関数を 削除できます。 注 リンカのフィードバックを最大限に活用するには、完全なコンパイルとリンクを 2 回 以上実行する必要があります。ただし、通常は、前回のビルドのフィードバックを使 用して 1 回コンパイルしてリンクすれば十分です。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-17 基本リンカ機能の使用 3.3.6 RW データ圧縮 通常、RW データ領域には、 (ゼロなどの)繰り返しの値が多数含まれるため、この領 域は圧縮に適しています。ROM サイズを小さくするため、RW データ圧縮は標準でイ ネーブルになっています。 ARM ライブラリにはいくつかの伸張アルゴリズムがあり、リンカは、イメージの実行 時にデータ領域を伸張するのに最適なアルゴリズムを選択して、イメージに追加しま す。ただし、リンカによって選択されたアルゴリズムはオーバーライドできます。 このセクションでは、データ圧縮について詳しく説明します。 • コンプレッサの選択 • 圧縮の適用方法(P. 3-19) • RW データ圧縮の使用(P. 3-20) コンプレッサの選択 armlink は、データセクションの内容に関する情報を収集してから、コードサイズを最 も小さくするのに最適な圧縮アルゴリズムを選択します。圧縮が適している場合、リ ンカは、イメージ内の圧縮可能なすべてのデータセクションに対して 1 つのデータコ ンプレッサしか使用できません。そのため、全体のサイズが最適になるようにこれら のセクションでさまざまな圧縮を行うことができます。以下の場合は、圧縮が自動的 に適用されます。 圧縮されたデータサイズ + デコンプレッサのサイズ < 圧縮されていないデータサイズ コンプレッサが選択されると、armlink によってイメージのコード領域にデコンプレッ サが追加されます。最終イメージに圧縮されたデータが含まれていない場合、デコン プレッサは追加されません。 リンカによって使用される圧縮は、以下のいずれかでオーバーライドできます。 • --datacompressor off オプションを使用して圧縮を無効にします。 • 使用するコンプレッサを明示的に指定します。 リンカに使用できるコンプレッサの一覧を取得するには、コマンドラインオプション --datacompressor list を使用します。以下に例を示します。 Num Compression algorithm ======================================================== 0 Run-length encoding 1 Run-length encoding, with LZ77 on small-repeats 2 Complex LZ77 compression 3-18 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 圧縮の適用方法 実行長の圧縮により、データは同じ値が繰り返されないバイトおよびゼロが繰り返さ れるバイト数の組み合わせとしてエンコードされます。同じ値が繰り返されないバイ トはそのまま出力され、その後、ゼロが繰り返されるバイト数が続きます。Limpel-Ziv 1977 (LZ77)圧縮では、読み込まれたデータの最後から n バイトが追跡されます。既 に読み込まれたデータに存在するフレーズが検出されると、既に読み込まれたバッ ファデータ内のフレーズの位置に対応する値のペアとそのフレーズの長さが出力され ます。 コンプレッサを指定するには、リンカのコマンドラインで必要な ID を使用します。以 下に例を示します。 armlink --datacompressor 2 ... コンプレッサを選択するときは、以下の点に注意して下さい。 • コンプレッサ 0 は、ゼロが繰り返される大きな領域とゼロ以外の値が繰り返され る小さな領域を持つデータに対してうまく機能します。 • コンプレッサ 1 は、ゼロ以外の値が繰り返されるデータに対してうまく機能し ます。 • コンプレッサ 2 は、同じ値が繰り返されるバイトを含むデータに対してうまく機 能します。 リンカでは、データの大部分がゼロが繰り返されるバイトの場合(75% を超える場合)、 コンプレッサ 0 または 1 が選択されます。データにゼロが繰り返されるバイトがほと んど含まれない場合(10% 未満の場合)、コンプレッサ 2 が選択されます。イメージが ARM コードのみで構成されている場合は、ARM デコンプレッサが自動的に使用され ます。イメージに Thumb コードが含まれる場合は、Thumb デコンプレッサが使用され ます。選択すべきコンプレッサが明確でない場合は、すべてのコンプレッサをテスト (P. 3-18) して、全体のサイズが最適になるものが選択されます(「コンプレッサの選択」 参照)。 注 独自のコンプレッサをリンカに追加することはできません。使用可能なアルゴリズム、 およびリンカによるアルゴリズムの選択方法は、今後変更される可能性があります。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-19 基本リンカ機能の使用 RW データ圧縮の使用 RW データ圧縮を使用するときは、以下の点に注意してください。 • リンカオプション --map を使用すると、コード内の領域で圧縮が適用されている 場所を表示できます。 • Load$$region_name$$Base シンボルが使用されている場合には圧縮を適 リンカは、 用しません。region_name には、同じロード領域で圧縮されたデータを含む任意 の実行領域を指定します。 • オンチップキャッシュを搭載した ARM プロセッサを使用している場合は、コー ドコヒーレンシの問題を回避するために、伸張後にキャッシュをイネーブルし ます。 詳細については、RealView Compilation Tools v3.0 Developer Guide の組み込みソフ トウェアの開発方法に関する章を参照して下さい。 RVCT v2.0 以前では、ルート領域に配置する必要があるのは __main セクションと領域 テーブルのみでした。RVCT v2.1 以上では、RW データ圧縮を使用するには、ルート領 域に追加のセクション(__dc*.o セクションなど)を配置する必要があります。 スキャッタローディング記述ファイルを使用する場合は、以下のようになります。 • コーディングでは、__dc*.o という名前のデコンプレッサオブジェクトをルート 領域に含める必要があります。以下に例を示します。 ER_ROOT { __main.o(*) * (Region$$Table) __scatter*.o(*) __dc*.o(*) } また、可能であれば、InRoot$$Sections を使用して、ルート領域内に必要なすべ てのライブラリセクションを配置します。以下に例を示します。 ER_ROOT { * (InRoot$$Sections) } 詳細については、 「ルート領域へのセクションの割り当て」(P. 5-37)を参照して 下さい。また、RealView Compilation Tools v3.0 Developer Guide の組み込みソフト ウェアの開発に関する章も参照して下さい。 • NOCOMPRESS 属性を追加して、ロード領域または実行領域が圧縮されないように指 「スキャッタローディング記述ファイルの正式な構文」 (P. 5-10)参照)。 定します( 3-20 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 3.3.7 ベニアの生成 ベニアは、リンカによって生成され、プログラムに挿入される小さなコードセクショ ンです。armlink は、分岐先が現在の状態の分岐範囲外にある場合にベニアを生成する 必要があります。 BL 命令の範囲は、ARM の場合は 32MB、Thumb-2 の場合は 16MB、Thumb の場合は 4MB です。このため、ベニアは、この命令の中間ターゲットとなり、分岐先アドレスを PC に設定することで、分岐の範囲を拡張できます。ARM と Thumb の混合環境では、ベニ アはプロセッサ状態も変更します。 armlink は、以下のタイプのベニアをサポートしています。 • ARM から ARM へ • ARM から Thumb へ(インターワークベニア) • Thumb から ARM へ(インターワークベニア) • Thumb から Thumb へ armlink は、ベニアごとに Veneer$$Code という名前の 1 つの入力セクションを作成しま す。ベニアは、他に要件を満たすことができる既存のベニアが存在しない場合にのみ 生成されます。2 つの入力セクションに同じ分岐先への長分岐が含まれている場合、生 成されるベニアは 1 つだけです。このようにベニアが共有されるのは、両方のセクショ ンから同じ分岐先に到達できる場合のみです。 ARMv4T を使用している場合、分岐によって ARM 状態と Thumb 状態の切り替えが発 生すると、armlink はベニアを生成します。ARMv5 以上では、BLX 命令が使用されます。 ベニアの共有 コマンドラインオプション --no_veneershare を使用すると、各実行領域でベニアが共 有されないように指定できます。これにより、作成されたベニアセクションの所有権 がベニアを作成したオブジェクトに割り当てられるため、スキャッタローディング記 述ファイル内の特定のオブジェクトからベニアを選択できます。以下に例を示します。 ER1 +0 { object1.o(Veneer$$Code) } ベニアを共有すると、所有するオブジェクトを割り当てることができなくなります。そ のため、--no_veneershare を使用すると、イメージのレイアウトの整合性を高めること ができます。ただし、このオプションには、コードサイズが大幅に増加するという欠 点もあります。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-21 基本リンカ機能の使用 ベニアのバリアント ベニアには、必要な分岐範囲に応じたさまざまなバリアントがあります。 • インラインベニア • 短分岐ベニア(P. 3-22) • 長分岐ベニア(P. 3-23) インラインベニア このバリアントには、以下の制限があります。 • ベニアは、範囲内に収まるようにターゲットセクションの直前に挿入する必要が あります。 • ARM から Thumb へのインターワークベニアの範囲は 256 バイトであるため、 関数コードはベニアコード直後から 256 バイトの範囲内に記述する必要があり ます。 • Thumb から ARM へのインターワークベニアの範囲はゼロバイトであるため、関 数コードはベニアコードの直後に記載する必要があります。 • インラインベニアは常に位置に依存しません。 これらの制限は、Veneer$$Code を使用してインラインベニアを実行領域の範囲外に移動 することができないことを意味します。コマンドラインオプション --no_inlineveneer を使用すると、インラインベニアが生成されなくなります。 短分岐ベニア このバリアントには、以下の制限があります。 • ARM から Thumb への短分岐ベニアの範囲は 4MB です。 3-22 • Thumb から ARM への短分岐ベニアの範囲は 32MB です。 • 短分岐ベニアは常に位置に依存しません。 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 長分岐ベニア このバリアントには、以下の制限があります。 • ARM から Thumb へのインターワークベニアおよび Thumb から ARM へのイン ターワークベニアの範囲はどちらも 232 バイトです。 • armlink は長分岐機能を状態変更機能に組み込むので、すべてのインターワーク ベニアは長分岐ベニアにもなります。 • 長分岐ベニアは、絶対または位置非依存のいずれかになります。 ベニアを使用する場合は、以下の点に注意して下さい。 • すべてのベニアを 1 つの入力セクションにまとめることはできません。これは、 結果として生じるベニア入力セクションが他の入力セクションの範囲内に収ま らない可能性があるためです。セクションがアドレス範囲内に存在しない場合、 長分岐は不可能です。 • armlink により、位置に依存しないベニアのバリアントが自動的に生成されます。 ただし、このようなベニアは位置に依存するバリアントよりも大きいため、必要 な場合(分岐元および分岐先の実行領域がどちらも位置に非依存で密接に関連し ている場合)にのみ、armlink がこの操作を行います。 ベニアは、コードサイズを最適化するために生成されます。そのため、armlink は、以 下の優先順序でバリアントを選択します。 1. インラインベニア 2. 短分岐ベニア 3. 長分岐ベニア 3.3.8 オーバーレイ実行領域へのベニアの再利用 armlink は可能な限りベニアを再利用します。ただし、ベニアを再利用するには、以下 の 2 つの条件があります。 • オーバーレイ実行領域では、他の実行領域内にあるベニアを再利用することはで きません。 • オーバーレイ実行領域内にあるベニアを、他の実行領域内で再利用することはで きません。 これらの条件が満たされない場合は、既存のベニアが再利用される代わりに、新しい ベニアが作成されます。スキャッタローディングを使用してベニアを特定の位置に配 置するようリンカに指示する場合を除き、ベニアは常に、ベニアを必要とする呼び出 しを含む実行領域内に配置されます。つまり、以下を意味します。 ARM DUI 0206GJ • オーバーレイ実行領域では、すべてのベニアがその実行領域内に配置されます。 • オーバーレイ実行領域では、他の実行領域内のベニアが必要になることはありま せん。 Copyright © 2002-2006 ARM Limited. All rights reserved. 3-23 基本リンカ機能の使用 3.3.9 分岐のインライン化 armlink では、すべてのプログラムコードをグローバルに可視化できるため、追加で分 岐の最適化を実行できます。 armlink は、分岐をインライン化して、イメージ内の小さな関数呼び出しを最適化しま す。小さな関数とは、BL 命令または BLX 命令の 4 バイトにインライン化できる 1 つの 命令関数です。このような関数では、分岐がないため、復帰アドレスが冗長になります。 注 分岐の最適化を有効にするとイメージが変更され、デバッグ情報が不適切になる可能 性があるため、分岐の最適化は通常はディセーブルになっています。分岐の最適化を イネーブルすると、デバッグ情報の修正は行われません。 分岐のインライン化を制御するには、以下のコマンドラインオプションを使用します。 --no_branchnop リンカでは、次の命令に解決することで再配置を行うすべての分岐を NOP に置き換えます。これは通常の動作です。ただし、検証やパイプラ インのフラッシュを実行する場合など、このオプションをディセーブル することが必要になる場合もあります。 この動作をディセーブルするには、--no_branchnop オプションを使用し ます。 分岐のインライン化をイネーブルします(「インライン化の制御」参照)。 --inline --tailreorder 可能であれば Tail の呼び出しセクションをターゲットの直前に移動し、 関数呼び出しを最適化します(「Tail の呼び出しセクションの処理」 (P. 3-26)参照)。 分岐のインライン化をイネーブルすると、armlink はイメージ内の各関数呼び出しをス キャンして、必要に応じてインライン化します。armlink は、関数をインライン化する と、呼び出し元から呼び出された関数への参照を削除します。armlink は、未使用セク ションが削除される前にこの最適化を適用するため、常にインライン化されるセク ションも削除できます。 分岐のインライン化に関する情報を表示するには、--info コマンドラインオプション を使用します。 3-24 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 --info inline 関数をインライン化するたびにメッセージが表示され、インラインの総 数を確認できます。以下に例を示します。 Small function inlining results Inlined 0x5c in Inlined 0x40 in . Inlined function __Heap_DescSize from object h1_alloc.o at offset section .text from object malloc.o. function __ieee_status from object istatus.o at offset section .text from object _printf_fp_dec.o. total of 6 calls. インライン化の制御 分岐のインライン化をイネーブルした場合、関数をインライン化するには、以下の条 件を満たしている必要があります。 • armlink は、最も単純な命令デバッグだけを処理し、PC への読み出しまたは書き 込みを行う命令をインライン化しません。これは、PC への読み出しや書き込み が関数の位置によって異なるためです。 • イメージに ARM コードと Thumb コードの両方が含まれている場合、他の状態か ら呼び出される関数はインターワーク用にビルドされる必要があります。ARM の呼び出し元は、等価な ARM 命令が使用可能な場合、呼ばれる側の Thumb 命令 をインライン化することができます。ただし、Thumb の呼び出し元は、呼ばれる 側の ARM 命令をインライン化することはできません。また、armlink は最高 2 つ の 16 ビット Thumb 命令もインライン化できますが、ARM の呼び出し元は 1 つ の 16 ビット Thumb 命令しかインライン化できません。 • リンカの動作は、関数を表すシンボルのサイズ、および表 3-2 に示す呼び出し元 (ARM または Thumb)と被発呼側(ARM または Thumb)によっても異なります。 表 3-2 小さな関数のインライン化 ARM DUI 0206GJ 呼び出し元 被発呼側 インライン化できる シンボルのサイズ ARM ARM 4 ~ 8 バイト ARM Thumb 2 ~ 6 バイト Thumb Thumb 2 ~ 6 バイト Thumb ARM 4 ~ 8 バイト Copyright © 2002-2006 ARM Limited. All rights reserved. 3-25 基本リンカ機能の使用 • インライン化するには、関数の最後の命令が以下のいずれかである必要があります。 MOV pc, rn または BX rn 復帰のシーケンスだけで構成される関数は、NOP としてインライン化できます。 • 条件付き ARM 命令をインライン化できるのは、BL の条件がインライン化する命 令の条件に一致するか、あるいはインライン化する BL またはインライン化する 命令に条件が付いていない場合のみです。例えば、BLEQ でインライン化できるの は、ADD のような無条件命令や ADDEQ のような条件が一致する命令だけです。 無条件の ARM BL は、他のすべての条件を満たす任意の条件付き命令または無条 件命令をインライン化できます。 • IT ブロックの最後の命令である BL は、16 ビットの Thumb 命令、あるいは 32 ビッ トの MRS、MSR、または CPS 命令をインライン化できません。これは、IT ブロック によりその有効範囲内の命令の動作が変更されるため、命令をインライン化する と、プログラムの動作が変更されるからです。 Tail の呼び出しセクションの処理 「インライン化の制御」 (P. 3-25)に記載されているとおり、リンカでは、次の命令に解 決することで再配置を行うすべての分岐を NOP に置き換えます。つまり、Tail の呼び出 しセクション(分岐命令で終わるセクション)は、そのセクションのターゲットが実 行領域内で直後に配置されるように最適化される場合があります。 コマンドラインオプション --tailreorder を使用して Tail の呼び出しセクションを ターゲットより上に移動することにより、この動作を利用できます。これが可能な場 合は、以下の点に注意して下さい。 • armlink は、1 つの Tail の呼び出しのターゲットにつき 1 つの Tail の呼び出しセ クションしか移動できません。1 つのセクションに対して複数の Tail 呼び出しが ある場合、同じセクション名の付いた Tail の呼び出しセクションがターゲットの 前に移動されます。一致する名前の付いた Tail の呼び出しセクションでセクショ ン名が見つからない場合、リンカは、最初に検出したセクションを移動します。 3-26 • Tail の呼び出しセクションをその実行領域から外部に移動できません。 armlink は、 • armlink は、Tail の呼び出しセクションをインラインベニアの前に移動しません。 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 Tail の呼び出しの最適化に関する情報を表示するには、--info コマンドラインオプショ ンを使用します。例えば、--info tailreorder を使用すると、移動した Tail の呼び出 しセクションに関する情報が表示されます。以下に例を示します。 Tailcall reorder results Tail calling Section !!!main from object __main.o placed before .text from kernel.o Tail calling Section .text from object rt_raise.o placed before .text from sys_exit.o Tail calling Section .text from object plibspace.o placed before .text from libspace.o Tail calling Section .text from object aeabi_idiv0.o placed before .text from rt_div0.o ...... ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-27 基本リンカ機能の使用 3.4 コマンドラインオプションを使用した単純イメージの作成 単純イメージは、RO、RW、および ZI の属性を持つ数多くの入力セクションから構成 されます。これらの入力セクションが照合されることにより、RO、RW、および ZI の 各出力セクションが形成されます。ロード領域と実行領域における出力セクションの 配置により、単純イメージは以下の 3 つの基本タイプに分類されます。 タイプ 1 ロードビューには 1 つの領域、実行ビューには連続する 3 つの領域が存 在します。このタイプのイメージを作成する場合は --ro-base オプショ ンを使用します。 詳細については、 「タイプ 1:1 つのロード領域と連続する出力領域」 (P. 3-29)を参照して下さい。 タイプ 2 ロードビューには 1 つの領域、実行ビューには連続しない 3 つの領域が 存在します。このタイプのイメージを作成する場合は --ro-base オプ ションおよび --rw-base オプションを使用します。 「タイプ 2:1 つのロード領域と連続しない出力領域」 詳細については、 3-30)を参照して下さい。 (P. タイプ 3 ロードビューには 2 つの領域、実行ビューには連続しない 3 つの領域が 存 在 し ま す。こ の タ イ プ の イ メ ー ジ を 作 成 す る 場 合 は、--ro-base、 --rw-base、および --split の 3 つのオプションを使用します。また、 --rosplit オプションを使用すると、標準の設定のロード領域を 2 つの RO 出力セクション(一方はコード用、もう一方はデータ用)に分割す ることもできます。 詳細については、「タイプ 3:2 つのロード領域と連続しない出力領域」 (P. 3-32)を参照して下さい。 どのタイプの単純イメージでも、使用できる実行領域は最高 3 つです。 • 最初の実行領域には RO 出力セクションが含まれます。 • 2 番目の実行領域には RW 出力セクションが含まれます(存在する場合)。 • 3 番目の実行領域には ZI 出力セクションが含まれます(存在する場合)。 これらの実行領域は、それぞれ RO 実行領域、RW 実行領域、ZI 実行領域と呼ばれます。 単純イメージはスキャッタローディング記述ファイルを使用して作成することもでき ます。この方法の詳細については、 「等価なスキャッタローディング記述を使用した単 純イメージの生成」(P. 5-42)を参照して下さい。 このセクションでは、単純イメージについて詳しく説明します。 • タイプ 1:1 つのロード領域と連続する出力領域(P. 3-29) • • 3-28 タイプ 2:1 つのロード領域と連続しない出力領域(P. 3-30) タイプ 3:2 つのロード領域と連続しない出力領域(P. 3-32) Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 3.4.1 タイプ 1:1 つのロード領域と連続する出力領域 このタイプのイメージは、ロードビュー内の 1 つのロード領域とメモリマップ内で連 続して配置されている 3 つの実行領域から構成されます。この方法は、OS のブート ローダ、Angel、デスクトップシステムなど、RAM にプログラムをロードするシステ ムに適しています(図 3-3 参照)。 ZI output section RAM RW output section RO output section --ro-base value Single load region ZI execution region RW output section RW execution region RO output section RO execution region 0x8000 0x0000 Load view Execution view 図 3-3 単純タイプ 1 のイメージ このタイプのイメージを作成するには以下のコマンドを使用します。 armlink --ro-base 0x8000 ロードビュー 単一のロード領域は、連続して配置された RO 出力セクションおよび RW 出力セクショ ンから構成されます。RO 実行領域と RW 実行領域はどちらもルート領域となります。 ロード時には ZI 出力セクションは存在しません。ZI 出力セクションは、実行前にイ メージファイル内の出力セクションの記述を使用して作成されます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-29 基本リンカ機能の使用 実行ビュー RO、RW、および ZI の各出力セクションを含む 3 つの実行領域は、連続して配置され ます。RO 実行領域と RW 実行領域の実行アドレスはロードアドレスと同じであるた め、ロードアドレスから実行アドレスに移動する必要があるものはありません。ただ し、ZI 出力セクションを含む ZI 実行領域は、実行開始前に作成されます。 RO 出力を含む領域のロードアドレスと実行アドレスを指定するには、armlink オプ シ ョ ン --ro-base address を使用します。標準の設定のアドレスは 0x8000 です (P. 3-29 図 3-3 参照)。 3.4.2 タイプ 2:1 つのロード領域と連続しない出力領域 このタイプのイメージは、1 つのロード領域と、実行ビュー内の 3 つの実行領域から構 成されます。RW 実行領域と RO 実行領域は隣接していません。この方法は、RW デー タが起動時に ROM から RAM にコピーされる、ROM ベースの組み込みシステムなど に使用されます(図 3-4 参照) 。 ZI output section RAM 0xA000 RW output section ZI execution region RW execution region --rw-base value Copy or decompress RW output section ROM RO output section Single load region RO output section RO execution region 0x0000 Load view --ro-base value Execution view 図 3-4 単純タイプ 2 のイメージ このタイプのイメージを作成するには以下のコマンドを使用します。 armlink --ro-base 0x0 --rw-base 0xA000 3-30 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 ロードビュー ロードビューでは、ROM などに連続して配置された RO 出力セクションおよび RW 出 力セクションによって 1 つのロード領域が構成されます。この場合、RO 領域はルート 領域となりますが、RW 領域はルート領域ではありません。ロード時には ZI 出力セク ションは存在しません。ZI 出力セクションは実行時に作成されます。 実行ビュー 実行ビューでは、最初の実行領域に RO 出力セクションが、2 番目の実行領域に RW 出 力セクションと ZI 出力セクションが含まれます。 RO 出力セクションを含む領域の実行アドレスとロードアドレスは同じであるため、 RO 出力セクションを移動する必要はありません。つまり、このセクションはルート領 域になります。 RW 出力セクションを含む領域の実行アドレスとロードアドレスは異なるため、RW 出 力セクションはロードアドレスから実行アドレスに(単一ロード領域から 2 番目の実 行領域に)移動されます。ZI 実行領域とその出力セクションは、RW 実行領域と隣接 して配置されます。 RO 出力セクションのロードアドレスおよび実行アドレスを指定するには、armlink オ プション --ro-base address を使用します。また、RW 出力セクションの実行アドレス を指定するには、--rw-base exec_address を使用します。--ro-base オプションでアド レスが指定されていない場合、armlink は標準の設定値 0x8000 を使用します。組み込み システムの場合、--ro-base の値には 0x0 を指定するのが一般的です。--rw-base オプ ションでアドレスが指定されていない場合、通常は、RW 出力セクションが RO 出力セ 「タイプ 1:1 つのロード領域と連続する出力領域」 クションのすぐ上に配置されます( (P. 3-29)参照)。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-31 基本リンカ機能の使用 3.4.3 タイプ 3:2 つのロード領域と連続しない出力領域 このタイプのイメージはタイプ 2 のイメージと似ていますが、このイメージでは 1 つ のロード領域が 2 つのロード領域に分割されます(図 3-5 参照)。 ZI output section RAM ZI execution region RW output section Second load region 0xE000 RW output section RW execution region RO output section First load region RO output section RO execution region --rw-base value --ro-base value 0x8000 0x0000 Load view Execution view 図 3-5 単純タイプ 3 のイメージ このタイプのイメージを作成するには以下のコマンドを使用します。 armlink --split --ro-base 0x8000 --rw-base 0xE000 ロードビュー ロードビューでは、最初のロード領域が RO 出力セクションで構成され、2 番目のロー ド領域が RW 出力セクションで構成されます。ロード時には ZI 出力セクションは存在 しません。ZI 出力セクションは、実行前にイメージファイル内の出力セクションの記 述を使用して作成されます。 3-32 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 実行ビュー 実行ビューでは、最初の実行領域に RO 出力セクションが、2 番目の実行領域に RW 出 力セクションと ZI 出力セクションが含まれます。 RO 領域の実行アドレスはロードアドレスと同じであるため、RO 出力セクションの内 容をロードアドレスから実行アドレスに移動またはコピーする必要はありません。RO 領域と RW 領域はどちらもルート領域となります。 また、RW 領域の実行アドレスもロードアドレスと同じであるため、RW 出力セクショ ンの内容はロードアドレスから実行アドレスに移動されません。ただし、ZI 出力セク ションは実行開始前に作成され、RW 領域の後に配置されます。 ロードアドレスと実行アドレスは、以下のリンカオプションを使用して指定します。 --split このオプションを指定すると、--ro-base と --rw-base を使用して 2 つの 領域を別々に配置できるように、標準の設定の 1 つのロード領域(RO 出 力セクションと RW 出力セクションを含む領域)が 2 つのロード領域(一 方が RO 出力セクションを、他方が RW 出力セクションを含む)に分割 されます。 --ro-base address RO セクションを含む領域のロードアドレスと実行アドレスに、4 バイト 境界で整列された address (例えば、ROM 内の先頭位置のアドレス)を 設定するように armlink に指示します。--ro-base オプションを使用して このアドレスが指定されていない場合、armlink は標準の設定値 0x8000 を使用します。 --rw-base address RW 出力セクションを含む領域の実行アドレスに、4 バイト境界で整列さ れた address を設定するように armlink に指示します。--split と共にこ のオプションを使用すると、RW 領域(ルート領域)のロードアドレス と実行アドレスの両方が指定されます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-33 基本リンカ機能の使用 3.5 コマンドラインオプションを使用した C++ 例外の処理 標準の設定、つまり、オプション --exceptions が指定されている場合は、イメージに 例外テーブルを含めることができます。コードで例外がスローされない場合、例外テー ブルは自動的に破棄されます。ただし、オプション --no_exceptions を指定すると、未 使用セクションの削除後に例外セクションが存在する場合、リンカによってエラーが 生成されます。 コードで例外が処理されないようにする場合は、--no_exceptions オプションを使用で きます。リンカは、エラーメッセージを生成して例外が検出されたことを通知し、最 終イメージを生成しません。 --no_exceptions オプションを --diag_warning オプションと組み合わせて使用 ただし、 すると、エラーメッセージを警告メッセージに降格できます。この場合、リンカは、 最終イメージを生成しますが、例外が検出されたことを警告するメッセージも生成し ます。 リンカは、従来のオブジェクト用に、デバッグフレーム情報を含む例外テーブルを作 成できます。この操作は、C 言語またはアセンブリ言語のオブジェクトについては支障 なく行うことができます。標準の設定では、リンカは例外テーブルを作成しません。こ れは、リンカオプション --exceptions_tables=nocreate を使用した場合と同じです。 リンカオプション --exceptions_tables=unwind を使用すると、リンカは、.debug_frame 情報を使用して、例外テーブルを含んでいないイメージのセクションごとに、レジス タが復元する unwind テーブルを作成できます。unwind テーブルを作成できない場合、 リンカは代わりに nounwind テーブルを作成します。 リンカオプション --exceptions_tables=cantunwind を使用すると、例外テーブルを含ん でいないイメージのセクションごとに nounwind テーブルを作成できます。 注 以下の点に注意して下さい。 3-34 • 標準の設定(つまり、--exceptions --exception_tables=nocreate)では、C コー ドがオプション --exceptions でコンパイルされる場合を除き、C コードまたはア センブリコードで例外をスローすることは安全ではありません。 • リンカは、RVCT v1.2 や ADS v1.2 など、従来の C++ コード内の自動変数に必要 なクリーンアップコードを生成できません。 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 3.6 イメージに関する情報の取得 --info オプションを使用して、リンカでイメージがどのように生成されたのかに関す る情報を取得できます。以下に例を示します。 armlink --info sizes ... ここでは、sizes によって、イメージ内の入力オブジェクトおよびライブラリのメンバ ごとにコードとデータのサイズが一覧表示されます。このオプションを使用すると、 --info sizes,totals を指定したことになります。 --info コマンドラインオプションに指定できるトピックキーワードの詳細について は、 「イメージ関連の情報の生成」(P. 2-30)を参照して下さい。 例 3-3 は、このオプションによる出力例を示しています。 例 3-3 イメージの詳細 Code (inc. data) 3712 0 0 21376 0 1580 0 0 648 0 RO Data RW Data ZI Data Debug 19 16 3 805 6 44 0 0 4 0 10200 0 0 300 0 7436 0 0 10216 0 Object Totals (incl. Generated) (incl. Padding) Library Totals (incl. Padding) =============================================================================== Code (inc. data) 25088 2228 25088 2228 RO Data 824 824 RW Data 48 48 ZI Data 10500 10500 Debug 17652 17652 Grand Totals Image Totals =============================================================================== Total RO Size (Code + RO Data) Total RW Size (RW Data + ZI Data) Total ROM Size (Code + RO Data + RW Data) 25912 ( 10548 ( 25960 ( 25.30kB) 10.30kB) 25.35kB) 例 3-3 では、出力が行と列で示され、合計は読みやすくするために区別されています。 詳細については、以下のサブセクションを参照して下さい。 • 列の詳細(P. 3-36) • ARM DUI 0206GJ 行の詳細(P. 3-36) Copyright © 2002-2006 ARM Limited. All rights reserved. 3-35 基本リンカ機能の使用 3.6.1 列の詳細 例 3-3(3-35 ページ)に示されているのは以下の項目です。 Code (inc. Data) コードで使用されるバイト数を示します。このイメージには、3712 バイ トのコードがあります。これには、リテラルプールや短いストリングな ど、1580 バイトのインラインデータ(inc. Data)が含まれています。 3.6.2 RO Data RW データ変数の初期値など、読み出し専用データが使用するバイト数 を示します。これは、Code (inc. Data) 列内のインラインデータに追加 されます。 RW Data 読み出し - 書き込みデータで使用されるバイト数を示します。 ZI Data ゼロで初期化されたデータで使用されるバイト数を示します。 Debug デバッグ入力セクション、シンボルテーブル、ストリングテーブルなど、 デバッグデータで使用されるバイト数を示します。 行の詳細 例 3-3(3-35 ページ)に示されているのは以下の項目です。 Object Totals イメージを生成するためにリンクされているオブジェクトで使用される バイト数を示します。 (incl. Generated) armlink は、インターワークベニアなどのイメージの内容や領域テーブ ルなどの入力セクションを生成する場合があります。 Object Totals 行に このタイプのデータが含まれている場合、イメージの内容に関するデー タがこの行に表示されます。例 3-3(3-35 ページ)では、RO データの合 計は 19 バイトで、そのうち 16 バイトがリンカで生成された RO データ です。 Library Totals 個別のオブジェクトとして抽出され、イメージに追加されたライブラリ のメンバで使用されるバイト数を示します。 3-36 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 基本リンカ機能の使用 (incl. Padding) armlink は、必要に応じてパディングを挿入し、セクションの境界調整を 強制実行します( 「セクションの整列」 (P. 3-10)参照) 。Object Totals 行 にこのタイプのデータが含まれている場合、パディングに関するデータ は関連する (incl. Padding) 行に示されます。同様に、Library Totals 行 にこのタイプのデータが含まれている場合、そのデータは関連する行に 示されます。例 3-3(3-35 ページ)では、RO データのオブジェクトの合 計は 19 バイトで、そのうち 3 バイトがリンカで生成されたパディングに なります。また、RO データのライブラリの合計は 805 バイトで、その うち 6 バイトがパディングになります。 例 3-3(3-35 ページ)に示されているのは以下の項目です。 Grand Totals イメージの実際のサイズを示します。例 3-3(3-35 ページ)では、10200 バイトの ZI データ(Object Totals)と 300 バイトの ZI データ(Library Totals)があるため、合計は 10500 バイトになります。 Image Totals RW データ圧縮(標準の設定)を使用して ROM サイズを最適化する場 合、最終イメージのサイズが変更され、このサイズ変更は --info による 出力に反映されます。Grand Totals と Image Totals のバイト数を比較す ると、圧縮の効果を確認できます。 例 3-3(3-35 ページ)では、RW データ圧縮がイネーブルになっていませ ん。データが圧縮されると、RW 値が変更されます(「RW データ圧縮」 (P. 3-18)参照)。 また、例 3-3(3-35 ページ)は、最終イメージのサイズの合計を(バイトおよびキロバ イト単位で)示しています。 --map オプションを使用すると、イメージのマップを作成できます。このマップは、イ メージの各ロード領域、実行領域、および入力セクションのアドレスとサイズを含ん でおり、RW データ圧縮の適用方法を示します( 「イメージ関連の情報の生成」 (P. 2-30) 参照)。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 3-37 基本リンカ機能の使用 3-38 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 第4章 イメージのシンボルへのアクセス 本章では、ARM® リンカ armlink でシンボルを参照する方法について説明します。本章 は以下のセクションから構成されています。 • ARM と Thumb の同義語(P. 4-2) • • • • • ARM DUI 0206GJ リンカ定義シンボルへのアクセス(P. 4-3) 別のイメージに含まれるシンボルへのアクセス(P. 4-8) グローバルシンボルの非表示と名前の変更(P. 4-12) $Super$$ と $Sub$$ を使用したシンボル定義のオーバーライド(P. 4-21) シンボルのバージョン管理(P. 4-22) Copyright © 2002-2006 ARM Limited. All rights reserved. 4-1 イメージのシンボルへのアクセス 4.1 ARM と Thumb の同義語 リンカでは、シンボルの複数の定義をイメージ内に共存させることができます。ただ し、各定義は異なるプロセッサ状態に関連付けられている必要があります。armlink で は、ARM と Thumb® の同義語を使用してシンボルを参照するとき、以下のような規則 が適用されます。 • ARM 状態のシンボルへの B、BL、または BLX 命令は、ARM 定義に従って解決さ れます。 • Thumb 状態のシンボルへの B、BL、または BLX 命令は、Thumb 定義に従って解決 されます。 シンボルへのその他の参照は、リンカが最初に検出した定義に従って解決されます。こ の場合、armlink では、警告を生成して該当シンボルを明示します。 4-2 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス 4.2 リンカ定義シンボルへのアクセス リンカで定義されるシンボルには、文字シーケンス $$ が含まれるものがあります。こ のようなシンボルと、文字シーケンス $$ を含む他の外部名は ARM で予約されている 名前です。これらのシンボルは、領域、出力セクション、入力セクションのそれぞれ のベースアドレスとその範囲を指定する目的で使用されます。 このようなシンボリックアドレスは、アセンブリ言語で記述されたプログラムでは再 配置可能なアドレスとしてインポートして使用できます。また、C または C++ で記述 されたソースコードからは extern シンボルとして参照できます。詳細については、 「リ ンカ定義シンボルのインポート」(P. 4-7)を参照して下さい。 注 リンカ定義シンボルは、コードから参照される場合にのみ生成されます。 このセクションでは、以下の内容について説明します。 • 領域関連シンボル • セクション関連シンボル(P. 4-6) • 4.2.1 リンカ定義シンボルのインポート(P. 4-7) 領域関連シンボル 領域関連シンボルは、リンカがイメージを作成するときに生成されます。表 4-1 は、イ メージ内に存在する実行領域ごとにリンカが生成するシンボルを示しています。 表 4-1 領域関連リンカシンボル ARM DUI 0206GJ シンボル 説明 Load$$region_name$$Base 領域のロードアドレス Image$$region_name$$Base 領域の実行アドレス Image$$region_name$$Length バイト単位の実行領域の長さ(4 の倍数) Image$$region_name$$Limit 実行領域末尾の次にあるバイトのアドレス Image$$region_name$$RO$$Base 指定領域内の RO 出力セクションの実行アドレス Image$$region_name$$RO$$Length バイト単位の RO 出力セクションの長さ(4 の倍数) Image$$region_name$$RO$$Limit 実行領域内の RO 出力セクション末尾の次にあるバ イトのアドレス Image$$region_name$$RW$$Base 指定領域内の RW 出力セクションの実行アドレス Image$$region_name$$RW$$Length バイト単位の RW 出力セクションの長さ(4 の倍数) Copyright © 2002-2006 ARM Limited. All rights reserved. 4-3 イメージのシンボルへのアクセス 表 4-1 領域関連リンカシンボル (続き) シンボル 説明 Image$$region_name$$RW$$Limit 実行領域内の RW 出力セクション末尾の次にあるバ イトのアドレス Image$$region_name$$ZI$$Base 指定領域内の ZI 出力セクションの実行アドレス Image$$region_name$$ZI$$Length バイト単位の ZI 出力セクションの長さ(4 の倍数) Image$$region_name$$ZI$$Limit 実行領域内の ZI 出力セクション末尾の次にあるバイ トのアドレス スキャッタローディングを使用しない場合、リンカでは region_name に以下の値を使用 します。 • ER_RO、読み出し専用領域の場合 • ER_RW、読み出し - 書き込み領域の場合 • ER_ZI、ゼロで初期化された領域の場合 ZI 出力セクションを含む各実行領域の場合、リンカでは $$ZI$$ を含む追加シンボルを 生成します。 注 4-4 • イメージの ZI 出力セクションは静的に作成されるのではなく、実行時に動的に 自動生成されます。そのため、ZI 出力セクションにはロードアドレスシンボルは ありません。 • セクション関連シンボルよりも領域関連シンボルを使用することをお勧めし ます。 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス スキャッタローディング記述ファイルの使用 スキャッタローディングを使用する場合は、記述ファイルでイメージ内のすべての実 行領域を命名し、各領域のロードアドレスと実行アドレスを指定します。 スキャッタローディング記述ファイルでスタックとヒープの両方を定義すると、リン カではスタックやヒープの特殊なシンボルも生成します。 「第 5 章 スキャッタローディング記述ファイルの使用」を参照して下 詳細については、 さい。 ZI 領域の上へのスタックとヒープの配置 領域関連シンボルの一般的な使用方法の 1 つは、ZI 領域のすぐ上にヒープを配置する 方法です。例 4-1 は、ターゲットが変更された __user_initial_stackheap() をアセンブ リ言語で作成する方法を示しています。この例では、ARM C ライブラリから標準の設 定の 1 領域メモリモデルを使用することを想定しています。詳細については、RealView Compilation Tools v3.0 Compiler and Libraries Guide の C および C++ のライブラリについ て説明した章の __user_initial_stackheap() の説明を参照して下さい。これを C 言語 で行う方法の例については、RealView Compilation Tools v3.0 Developer Guide のプロセッ サ例外処理について説明した章の例 retarget.c の説明も参照して下さい。 例 4-1 ZI 領域の上へのスタックとヒープの配置 EXPORT __user_initial_stackheap IMPORT ||Image$$region_name$$ZI$$Limit|| __user_initial_stackheap LDR r0, =||Image$$region_name$$ZI$$Limit|| MOV pc, lr ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 4-5 イメージのシンボルへのアクセス 4.2.2 セクション関連シンボル 表 4-2 に示す出力セクションのシンボルは、コマンドラインオプションを使用して単純 イメージを作成する場合に生成されます。単純イメージには、3 つの実行領域を生成す る 3 つの出力セクション(RO、RW、ZI)があります。表 4-2 は、イメージ内に存在す る入力セクションごとにリンカが生成する入力シンボルを示しています。 リンカでは、実行領域内のセクションを、まず、属性 RO、RW、または ZI でソートし、 次に名前でソートします。したがって、例えば .text セクションはすべて連続する 1 つ のブロックに配置されます。同じ属性と名前を持つセクションが連続するブロックを 統合セクションと呼びます。 表 4-2 セクション関連リンカシンボル シンボル セクションの種類 説明 Image$$RO$$Base 出力 RO 出力セクションの開始アドレス Image$$RO$$Limit 出力 RO 出力セクション末尾の次にあるバ イトのアドレス Image$$RW$$Base 出力 RW 出力セクションの開始アドレス Image$$RW$$Limit 出力 ZI 出力セクション末尾の次にあるバ イトのアドレス(RW 領域の末尾では なく、ZI 領域の末尾を選択しているの は、従来のコードとの互換性を維持す るためです) Image$$ZI$$Base 出力 ZI 出力セクションの開始アドレス Image$$ZI$$Limit 出力 ZI 出力セクション末尾の次にあるバ イトのアドレス SectionName$$Base 入力 SectionName という名前の統合セクショ ンの開始アドレス SectionName$$Length 入力 SectionName という名前の統合セクショ ンの長さ(バイト単位) SectionName$$Limit 入力 SectionName という名前の統合セクショ ン末尾の次にあるバイトのアドレス 4-6 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス 注 コードから入力セクションのシンボルを参照する場合、イメージ内の同じ名前のすべ ての入力セクションは、イメージメモリマップ内に連続して配置されると想定できま す。入力セクションのベースシンボルとリミットシンボルが不連続なメモリ上で使用 されると、通常、予測不能な望ましくない結果が生じるので、スキャッタローディン グ記述で入力セクションが連続して配置されない場合は、リンカではエラーと診断し ます。 スキャッタローディング記述ファイルを使用する場合、P. 4-6 表 4-2 の出力セクション シンボルは定義されません。コードからこうしたシンボルを参照する場合は、weak 型 の参照として処理する必要があります。 __user_initial_stackheap() の標準実装では、Image$$ZI$$Limit の値を使用します。 したがって、スキャッタローディング記述ファイルを使用する場合は、 __user_initial_stackheap() を再実装して、ヒープとスタックの境界を設定する必要 のある場合があります。詳細については、「第 5 章 スキャッタローディング記述ファ イルの使用」を参照して下さい。 4.2.3 リンカ定義シンボルのインポート C または C++ で記述されたソースコードにリンカ定義シンボルをインポートするに は、2 つの方法があります。以下のいずれかの方法を使用します。 extern unsigned int symbol_name; または extern void *symbol_name; シンボルを int で宣言する場合は、例 4-2 に示すように、アドレス演算子(&)を使用 して適切な値を取得する必要があります。 例 4-2 リンカ定義シンボルのインポート extern unsigned int Image$$ZI$$Limit config.heap_base = (unsigned int) &Image$$ZI$$Limit ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 4-7 イメージのシンボルへのアクセス 4.3 別のイメージに含まれるシンボルへのアクセス あるイメージから別のイメージに含まれるグローバルシンボルの値を参照する場合 は、シンボル定義(symdefs)ファイルを使用できます。 例えば、ROM に常駐するイメージが 1 つ、RAM にロードされるイメージが複数存在 する場合に、このファイルを使用できます。この場合、RAM にロードされるイメージ から、ROM 内に存在するイメージのグローバル関数やグローバルデータにアクセスで きます。 このセクションでは、以下の内容について説明します。 • symdefs ファイルの作成 4.3.1 • symdefs ファイルの読み出し(P. 4-9) • symdefs ファイルの形式(P. 4-10) symdefs ファイルの作成 symdefs ファイルを生成するには、armlink のオプション --symdefs filename を使用し ます。 リンカでは、リンクの最終段階が正常に処理されたときに symdefs ファイルを作成しま す。部分的なリンクの場合、またはリンクの最終段階が正常に処理されなかった場合 はファイルは作成されません。 注 filename が存在しない場合は、すべてのグローバルシンボルを含むファイルが作成さ れます。filename が存在する場合は、既存の filename の内容を使用して、リンカから のファイルの再書き込み時に出力するシンボルを選択します。この処理が必要ない場 合は、リンク手順の前に既存の symdefs ファイルをすべて削除して下さい。 4-8 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス グローバルシンボルのサブセットの出力 標準の設定では、すべてのグローバルシンボルが symdefs ファイルに書き込まれます。 filename が存在する場合、リンカではそのファイルの内容を使用して、出力をグロー バルシンボルのサブセットに限定します。出力シンボルは、以下の手順で限定するこ とができます。 1. image1 のリンクの最終段階直前に --symdefs filename を指定します。リンカで は、symdefs ファイル filename が作成されます。 2. テキストエディタで filename を開き、最終リストに不要なシンボルエントリを 削除してからファイルを保存します。 3. image1 のリンクの最終段階で --symdefs filename を指定します。 image1 の作成に使用していたオブジェクトがいくつか変更されたときにシンボ ル定義を更新する場合など、いつでも filename を編集してコメントを追加し、 image1 を再リンクできます。 4.3.2 symdefs ファイルの読み出し symdefs ファイルは、コードやデータを含まない、シンボル情報だけを含むオブジェク トファイルと考えることができます。symdefs ファイルを読み出すには、オブジェクト ファイルを追加するのと同様にこのファイルをファイルリストに追加します。リンカ では、このファイルを読み出し、シンボルとその値を出力シンボルテーブルに追加し ます。追加されるシンボルには、ABSOLUTE 属性と GLOBAL 属性があります。 部分的なリンクが実行される場合、シンボルは出力オブジェクトのシンボルテーブル に追加されます。完全なリンクが実行される場合、シンボルはイメージのシンボルテー ブルに追加されます。 リンカでは、ファイル内に無効な行があるとエラーメッセージを生成します。行は、以 下の場合に無効になります。 • 不足している列がある場合 • 無効な値を含む列がある場合 symdefs ファイルから抽出されるシンボルは、オブジェクトのシンボルテーブルから抽 出されるシンボルとまったく同じ方法で処理されます。複数のシンボル定義および ARM/Thumb の同義語に関しても、同じ制限が適用されます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 4-9 イメージのシンボルへのアクセス 4.3.3 symdefs ファイルの形式 symdefs ファイルにはシンボルとその値が含まれます。ただし、他のオブジェクトファ イルとは異なり、コードやデータは含まれません。 ファイルは、例 4-3 に示すように、識別行、オプションのコメント、およびシンボル情 報から構成されます。 例 4-3 symdefs ファイルの形式 #<SYMDEFS># ARM Linker, RVCT3.0 [Build num]: Last Updated: Date ;value type name, this is an added comment 0x00008000 A __main 0x00008004 A __scatterload 0x000080e0 T main 0x0000814d T _main_arg 0x0000814d T __argv_alloc 0x00008199 T __rt_get_argv ... # This is also a comment, blank lines are ignored ... 0x0000a4fc D __stdin 0x0000a540 D __stdout 0x0000a584 D __stderr 0xfffffffd N __SIG_IGN 識別ストリング テキストファイル内の最初の 11 文字が #<SYMDEFS># の場合、リンカではそのファイル を symdefs ファイルとして認識します。 識別ストリングの後には、リンカのバージョン情報と、symdefs ファイルを最後に更新 した日付と時刻が続きます。バージョン情報と更新情報は識別ストリングの一部では ありません。 4-10 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス コメント コメントは、テキストエディタを使用して手動で挿入できます。コメントには、以下 の特性があります。 • 先頭行は、特殊な識別コメント #<SYMDEFS># で始まる必要があります。このコメ ントは、ファイル作成時にリンカによって挿入されます。このコメントを手動で 削除しないで下さい。 • 空白以外の最初の文字がセミコロン(;)またはハッシュ(#)の行は、すべてコ メントです。 • 空白以外の最初の文字の後にセミコロン(;)またはハッシュ(#)がある行は、 コメントではありません。 • 空白行は無視されます。よって読みやすくするために空白行を挿入できます。 シンボル情報 シンボル情報は、シンボルのアドレス、タイプ、名前から構成され、1 行に記述されます。 シンボルの値 リンカでは、シンボルの絶対アドレスを固定長の 16 進形式(例 0x00008000)で書き込みます。このファイルを編集する場合、ア ドレス値には 16 進形式と 10 進形式のどちらも使用できます。 タイプフラグ シンボル名 ARM DUI 0206GJ シンボルのタイプは 1 文字で以下のように表されます。 A ARM コード T Thumb コード D データ N 数値 シンボルの名前です。 Copyright © 2002-2006 ARM Limited. All rights reserved. 4-11 イメージのシンボルへのアクセス 4.4 グローバルシンボルの非表示と名前の変更 このセクションでは、ステアリングファイルを使用して、出力ファイル内のシンボル を管理する方法について説明します。例えば、ステアリングファイルを使用して、知 的所有権を保護したり、ネームスペースのクラッシュを回避したりできます。ステア リングファイルは、出力オブジェクトのシンボルテーブルを編集するための一連のコ マンドが含まれるテキストファイルです。 armlink のコマンドラインオプション --edit file-list を使用して、ステアリングファ イルを指定します(詳細については、 「armlink のコマンド構文」(P. 2-10)の --edit オ プションの説明を参照して下さい)。複数のステアリングファイルを指定する場合の構 文は、以下のいずれかを使用できます。 armlink --edit file1 --edit file2 --edit file3 armlink --edit file1,file2,file3 コンマとファイル名の間にスペースを含めないで下さい。 このセクションでは、以下の内容について説明します。 • ステアリングファイルの形式 • ステアリングファイルのコマンド(P. 4-13) 4.4.1 ステアリングファイルの形式 ステアリングファイルは、以下の形式のプレーンテキストファイルです。 4-12 • 空白以外の最初の文字がセミコロン(;)またはハッシュ(#)文字の行は、コメ ント行として解釈されます。コメントは空白行として処理されます。 • 空白行は無視されます。 • 空白行でもコメント行でもない行は、コマンドか、連続する空白以外の行に分割 されたコマンドの一部です。 • 空白以外の最後の文字がコンマ(,)で終わるコマンドラインは、次の空白行以外 の行に続きます。 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス 各コマンドラインは、コマンドとそれに続くコンマで区切られたオペランドグループ から構成されます(複数可)。各オペランドグループは、コマンドによって 1 つまたは 2 つのオペランドで構成されます。コマンドは、そのコマンドの各オペランドグループ に適用されます。この場合、以下の規則が適用されます。 • コマンドでは大文字と小文字が区別されませんが、通常は大文字で表示されます。 • オペランドは大文字と小文字が区別されるシンボル名とマッチングする必要が あるため、大文字と小文字が区別されます。オペランドにはワイルドカード文字 を使用できます。 コマンドは、グローバルシンボルのみに適用されます。ローカルシンボルや STT_FILE などのその他のシンボルには影響しません。 4.4.2 ステアリングファイルのコマンド ステアリングファイルのコマンドでは、以下のことが可能です。 • シンボルテーブル内のシンボルを管理する。 • 静的シンボルテーブルから動的シンボルテーブルへのシンボルのコピーを制御 する。 • リンクユニットが依存するライブラリに関する情報を保存する。 注 ステアリングファイルのコマンドは、グローバルシンボルのみを制御します。ローカ ルシンボルはどのコマンドの影響も受けません。 以下のコマンドがサポートされています。 • IMPORT(P. 4-14) ARM DUI 0206GJ • EXPORT(P. 4-15) • RENAME(P. 4-16) • RESOLVE(P. 4-17) • REQUIRE(P. 4-19) • HIDE(P. 4-19) • SHOW(P. 4-20) Copyright © 2002-2006 ARM Limited. All rights reserved. 4-13 イメージのシンボルへのアクセス IMPORT IMPORT コマンドでは、シンボルが実行時に共有オブジェクトで定義されることを指定 します。 構文 IMPORT [pattern AS] replacement_pattern [,[pattern AS] replacement_pattern]* 各パラメータには以下の意味があります。 0 個以上の未定義のグローバルシンボルに一致するワイルドカード文字 (* ま た は ?)をオプションで含めることができるストリングです。 replacement_pattern がどの未定義グローバルシンボルとも一致しない 場合、リンカではそのコマンドを無視します。オペランドは、未定義の グローバルシンボルのみとマッチングを行うことができます。 pattern replacement_pattern ワイルドカード文字(* または ?)をオプションで含めることができるス トリングです。未定義グローバルシンボルの名前は、ここで指定した名 前に変更されます。ワイルドカード文字は pattern 内のワイルドカード 文字と対応している必要があります。pattern 内のワイルドカード文字に 一致する文字が、replacement_pattern のワイルドカード文字に置き換わ ります。 以下に例を示します。 IMPORT my_func AS func1 未定義シンボル my_func をインポートし、名前を func1 に変更します。 使用法 現在の共有オブジェクトまたは実行可能ファイルで定義されているシンボルはイン ポートできません。IMPORT では、ワイルドカード文字(* または ?)は 1 文字しか使用 できません。 動的シンボルテーブルが存在する場合、未定義シンボルは(指定されている場合は pattern として、それ以外の場合は replacement_pattern として)動的シンボルテーブ ルに含まれます。 注 IMPORT コマンドは、未定義グローバルシンボルのみに影響します。共有ライブラリに よって解決されたシンボルは、動的シンボルテーブルに暗黙にインポートされます。リ ンカでは、暗黙にインポートされたシンボルをターゲットとする IMPORT ディレクティ ブはすべて無視されます。 4-14 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス EXPORT EXPORT コマンドは、他の共有オブジェクトまたは実行可能ファイルからシンボルにア クセスできることを指定します。 構文 EXPORT pattern [AS replacement_pattern] [,pattern [AS replacement_pattern]]* 各パラメータには以下の意味があります。 pattern 0 個以上の定義済みグローバルシンボルに一致するワイルドカード文字 (* ま た は ?)をオプションで含めることができるストリングです。 pattern がどの定義済みグローバルシンボルとも一致しない場合、 リンカ ではそのコマンドを無視します。オペランドは、定義済みグローバルシ ンボルのみとマッチングを行うことができます。 replacement_pattern ワイルドカード文字(* または ?)をオプションで含めることができるス トリングです。定義済みグローバルシンボルの名前は、ここで指定した 名前に変更されます。ワイルドカード文字は replacement_pattern 内のワ イルドカード文字と対応している必要があります。replacement_pattern 内のワイルドカード文字に一致する文字が、pattern のワイルドカード文 字に置き換わります。 以下に例を示します。 EXPORT my_func AS func1 定義済みシンボル my_func の名前を func1 に変更し、エクスポートし ます。 使用法 シンボルを既に存在する名前にエクスポートすることはできません。EXPORT では、ワ イルドカード文字(* または ?)は 1 文字しか使用できません。 動的シンボルテーブルが存在する場合、定義済みシンボルは(指定されている場合は replacement_pattern として、それ以外の場合は pattern として)動的シンボルテーブ ルに含まれます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 4-15 イメージのシンボルへのアクセス RENAME RENAME コマンドは、定義済みおよび未定義のグローバルシンボルの名前を変更します。 構文 RENAME pattern AS replacement_pattern [,pattern AS replacement_pattern]* 各パラメータには以下の意味があります。 pattern 0 個以上のグローバルシンボルに一致するワイルドカード文字(* また は ?)をオプションで含めることができるストリングです。pattern が どのグローバルシンボルとも一致しない場合、リンカではそのコマン ドを無視します。オペランドは、定義済みと未定義のグローバルシン ボルのどちらともマッチングを行うことができます。 replacement_pattern ワイルドカード文字(* または ?)をオプションで含めることができる ストリングです。グローバルシンボルの名前は、ここで指定した名前に 変更されます。ワイルドカード文字は pattern 内のワイルドカード文字 と対応している必要があります。pattern 内のワイルドカード文字に一 致する文字が、replacement_pattern のワイルドカード文字に置き換わり ます。 例えば、シンボルの名前が func1 の場合。 RENAME f* AS my_f* 名前 func1 を my_func1 に変更します。 使用法 ターゲットのシンボル名自体が変更されている場合でも、シンボルの名前を既存の名 前に変更することはできません。RENAME では、ワイルドカード文字(* または ?)は 1 文字しか使用できません。例えば、シンボル func1、func2、および func3 を含むイメー ジがあるとします。 EXPORT func1 AS func2 RENAME func3 AS b2 EXPORT func1 AS func3 ;invalid, func2 exists ;invalid, func3 exists, even though it is renamed to b2 リンカでは、置き換えを行う前にステアリングファイルを処理します。そのため、1 行 目で RENAME A AS B を使用し、2 行目で RENAME B AS A を使用することはできません。 4-16 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス RESOLVE RESOLVE コマンドは、特定の未定義参照と定義済みグローバルシンボルのマッチングを 行います。 構文 RESOLVE pattern AS defined_pattern 各パラメータには以下の意味があります。 pattern 定義済みグローバルシンボルに一致する必要のあるワイルドカード文字 をオプションで含めることができるストリングです。 defined_pattern 0 個以上の定義済みグローバルシンボルに一致するワイルドカード文字 をオプションで含めることができるストリングです。defined_pattern が どの定義済みグローバルシンボルとも一致しない場合、リンカではその コマンドを無視します。未定義参照と未定義シンボルのマッチングを行 うことはできません。 使用法 RESOLVE は、既存の armlink --unresolved コマンドラインオプションを拡張するコマン ドです。--unresolved ではすべての未定義参照について 1 つの定義とのマッチングを行 うことができるのに対して、RESOLVE ではより限定的な参照とシンボルのマッチングを 行うことができる点が異なります。 未定義参照は、出力シンボルテーブルから削除されます。 RESOLVE は、部分的なリンクを実行するときでも、通常のリンクを実行するときでも機 能します。 例えば、例 4-4(4-18 ページ)に示すように、2 つのファイル file1.c と file2.c があ るとします。ここで、RESOLVE MP3* AS MyMP3* という行を含む ed.txt ファイルを作成 し、以下のコマンドを発行します。 armlink file1.o file2.o --edit ed.txt --unresolved foobar ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 4-17 イメージのシンボルへのアクセス このコマンドでは、以下の処理が行われます。 • file1.o からの参照(foo、MP3_Init()、MP3_Play())は、ステアリングファイル ed.txt での指定に従って、file2.o の定義(foobar、MyMP3_Init()、MyMP3_Play()) とそれぞれマッチングが行われます。 • ed.txt で指定されている RESOLVE コマンドでは、MP3 関数のマッチングが行われ、 --unresolved オプションによって、残りのすべての参照のマッチングが行われま す。この場合は、foo と foobar のマッチングが行われます。 • イメージか部分的にリンクされるオブジェクトかどうかとは無関係に、出力シン ボルテーブルには、シンボル foo、MP3_Init、および MP3_Play はいずれも含まれ ません。 例 4-4 file1.c extern int foo; extern void MP3_Init(void); extern void MP3_Play(void); int main(void) { int x = foo + 1; MP3_Init(); MP3_Play(); return x; } file2.c: int foobar; void MyMP3_Init() { } void MyMP3_Play() { } 4-18 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス REQUIRE REQUIRE コマンドは、ダイナミック配列内に DT_NEEDED タグを作成します。DT_NEEDED タ グは、アプリケーションで使用されている共有ライブラリなどの他の共有オブジェク トとの依存関係を指定します。 構文 REQUIRE pattern [,pattern]* 各パラメータには以下の意味があります。 pattern ファイル名を表すストリングです。ワイルドカードは使用できません。 使用法 リンカでは、pattern の値を含む DT_NEEDED タグをダイナミック配列に挿入します。こ のタグは、ダイナミックローダが現在ロードしているファイルでは pattern をロードす る必要があることをローダに通知します。 注 REQUIRE コマンドの結果として挿入される DT_NEEDED タグは、コマンドラインで配置 される共有オブジェクトまたは DLL から生成される DT_NEEDED タグの後に追加され ます。 HIDE HIDE コマンドは、シンボルテーブル内の定義済みグローバルシンボルを匿名にします。 構文 HIDE pattern [,pattern]* 各パラメータには以下の意味があります。 pattern ARM DUI 0206GJ 0 個以上の定義済みグローバルシンボルに一致するワイルドカード文字 をオプションで含めることができるストリングです。pattern がどの定義 済みグローバルシンボルとも一致しない場合、リンカではそのコマンド を無視します。未定義シンボルを非表示にすることはできません。 Copyright © 2002-2006 ARM Limited. All rights reserved. 4-19 イメージのシンボルへのアクセス 使用法 HIDE コマンドと SHOW コマンドを使用して、出力イメージ内または部分的にリンクされ たオブジェクト内の特定のグローバルシンボルを匿名にできます。例 4-5 で示すよう に、オブジェクトファイル内またはライブラリ内でシンボルを非表示にすることは、知 的所有権を保護する手段としても有効です。この例では、os_ で始まるグローバルシン ボル以外のすべてのグローバルシンボルを非表示にして、部分的にリンクされるオブ ジェクトを作成します。 例 4-5 steer.txt HIDE * SHOW os_* ; Hides all global symbols ; Shows all symbols beginning with 弛 s_í この例を以下のコマンドでリンクします。 armlink --partial input_object.o --edit steer.txt -o partial_object.o この例は、非表示のシンボルへの参照を含まない他のオブジェクトとリンクできます。 出力オブジェクト内でシンボルが非表示になっている場合は、その後のリンク手順で 非表示のシンボルに対して SHOW コマンドを使用しても効果はありません。非表示の参 照は、出力シンボルテーブルから削除されます。 SHOW SHOW コマンドは、それ以前に HIDE コマンドで非表示にしたグローバルシンボルを表示 します。このコマンドは、ワイルドカードを指定した HIDE コマンドを使用して非表示 にした特定のシンボルを表示する場合に便利です。 構文 SHOW pattern [,pattern]* 各パラメータには以下の意味があります。 pattern 0 個以上のグローバルシンボルに一致するワイルドカード文字をオプ ションで含めることができるストリングです。pattern がどのグローバル シンボルとも一致しない場合、リンカではそのコマンドを無視します。 使用法 SHOW の使用方法は HIDE の使用方法と密接に関連しています。詳細については、 「HIDE」 (P. 4-19)を参照して下さい。 4-20 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス 4.5 $Super$$ と $Sub$$ を使用したシンボル定義のオーバーライド 外部ライブラリや ROM コード内に含まれているなどの理由で、既存のシンボルを変更 できない場合があります。 このような場合、$Super$$ パターンと $Sub$$ パターンを使用して既存のシンボルに パッチを適用します。 例えば、関数 foo() の定義にパッチを適用するには、以下のように $Super$$foo() と $Sub$$foo() を使用します。 $Super$$foo パッチを適用していない元の関数 foo() を識別します。このパターンを 使用して、元の関数を直接呼び出します。 $Sub$$foo 元の関数 foo() の代わりに呼び出す新しい関数を識別します。このパ ターンを使用して、元の関数の前または後に処理を追加します。 例 4-6 は、結果として ExtraFunc() および foo() を呼び出すように変更された既存の 関数 foo() を示しています。詳細については、 install_directory\Documentation\Specifications\... にある ARM ELF の仕様 (aaelf.pdf)を参照して下さい。 例 4-6 extern void ExtraFunc(void); extern void $Super$$foo(void): /* this function will be called instead of the original foo() */ void $Sub$$foo(void) { ExtraFunc(); /* does some extra setup work */ $Super$$foo(); /* calls the original foo() function */ } ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 4-21 イメージのシンボルへのアクセス 4.6 シンボルのバージョン管理 リンカは Base Platform ABI for the ARM Architecture [BPABI]に準拠し、GNU 拡張シン ボルバージョン管理モデルをサポートします。 シンボルのバージョン管理では、シンボルのインポート元およびエクスポート先の動 的な共有オブジェクトに関する追加情報を記録します。ダイナミックローダでは、こ の追加情報を使用して、イメージで必要なすべてのシンボルがロード時に利用可能に なるようにします。 共有オブジェクトの作成者は、シンボルのバージョンを管理することで、すべての新 しいクライアントが使用できる新しいバージョンのシンボルを作成すると同時に、古 いバージョンの共有オブジェクトにリンクするクライアントとの互換性を維持するこ とができます。 このセクションでは、以下の内容について説明します。 • バージョン • 標準の設定のバージョン • バージョン管理シンボルの作成 4.6.1 バージョン シンボルのバージョン管理により、動的シンボルテーブルにバージョンという概念が 追加されます。バージョンとは、シンボルが関連付けられる名前です。ダイナミック ローダがバージョン名に関連付けられたシンボル参照を解決する際、同じバージョン 名のシンボル定義に対してのみマッチングを行うことができます。 注 共有オブジェクトのリビジョン履歴を示すために、バージョンを以前のバージョン名 に関連付けることができます。 4.6.2 標準の設定のバージョン 共有オブジェクトに同じシンボルの複数のバージョンを含めることはできますが、共 有オブジェクトのクライアントは最新バージョンにしかバインドできません。 このバインドできる最新バージョンをシンボルの標準の設定のバージョンと呼びます。 4-22 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス 4.6.3 バージョン管理シンボルの作成 リンカは、標準の設定では共有オブジェクトにバージョン管理シンボルを作成しませ ん。バージョン管理シンボルを制御するには、以下の 3 つの方法があります。 • • • 組み込みシンボル(P. 4-23) ステアリングファイル(P. 4-24) ファイル名(P. 4-25) 組み込みシンボル 入力オブジェクトに、リンカでシンボルバージョンが作成されるようにする特定の 名前付きシンボルを追加できます。追加できるシンボルは、以下のような形式にな ります。 • name@version(標準の設定のバージョン以外のシンボルの場合) • name@@version(標準の設定のバージョンのシンボルの場合) このようなシンボルは、エクスポートを考えている関数やデータのアドレスで定義す る必要があります。シンボル名は、シンボル名部分(name)とバージョン定義部分(ver) の 2 つから構成されます。name 部分は動的シンボルテーブルに追加され、共有オブジェ クトへのインターフェイスの一部になります。ver がまだ存在しない場合は、ver とい う名前のバージョンを作成し、name を ver という名前のバージョンに関連付けます。 バージョンシンボルの作成方法の詳細については、以下を参照して下さい。 • RealView Compilation Tools v3.0 Compiler and Libraries Guide の ARM コンパイラの 使用方法に関する章 • RealView Compilation Tools v3.0 Assembler Guide の ARM および Thumb アセンブリ 言語の記述方法に関する章 例 4-7 では、シンボル foo@ver1、foo@@ver2、および bar@@ver1 をオブジェクトシンボ ルテーブルに配置します。 例 4-7 バージョン管理シンボルの作成、組み込みシンボル int old_function(void) __asm__("foo@ver1"); int new_function(void) __asm__("foo@@ver2"); int other_function(void) __asm__("bar@@ver1"); リンカではこれらのシンボルを読み出し、バージョン定義 ver1 と ver2 を作成します。 シンボル foo は標準の設定のバージョン以外の ver1 と標準の設定のバージョンの ver2 に関連付けられます。シンボル bar は標準の設定のバージョンの ver1 に関連付けられ ます。 この方法では、複数のバージョン間の関連付けを作成することはできません。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 4-23 イメージのシンボルへのアクセス ステアリングファイル シ ン ボ ル バ ー ジ ョ ン を 作 成 す る コ マ ン ド を、コ マ ン ド ラ イ ン オ プ シ ョ ン --symver_script file で指定されたスクリプトファイルに組み込むことができます。こ のオプションを使用すると、自動的にシンボルのバージョン管理が可能になります。 スクリプトファイルでは、GNU ld および Sun Solaris リンカと同じ構文をサポートし ます。 スクリプトファイルを使用することで、バージョンを以前のバージョンに関連付ける ことができます。 ステアリングファイルと組み込みシンボル方式は組み合わせて指定できます。これを 行う場合は、スクリプトファイルと組み込みシンボルを一致させ、以下のようにバッ カスナウア記法(BNF)の形式を使用する必要があります。 version_definition ::= version_name "{" symbol_association* "}" [depend_version] ";" version_name は、バージョンの名前を含むストリングです。depend_version は、この version_name が依存するバージョンの名前を含むストリングです。このバージョンは、 スクリプトファイル内で事前に定義されている必要があります。バージョン名は重要 ではありませんが、以下のように読みやすい名前を付けることで役立ちます。 symbol_association ::= "local:" | "global:" | symbol_name ";" 各パラメータには以下の意味があります。 • "local:" は、このバージョン定義でこれに続くすべての symbol_name が共有オ ブジェクトに対してローカルであり、バージョン管理されないことを示してい ます。 • "global:" は、これに続くすべての symbol_name がこのバージョン定義に所属す ることを示します。 各バージョン定義の始めには暗黙の "global:" が存在します。 • 4-24 symbol_name は、静的シンボルテーブル内のグローバルシンボルの名前です。 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ イメージのシンボルへのアクセス 例 4-8 は、組み込みシンボルの例(例 4-7(4-23 ページ))に対応し、ver2 が ver1 に依 存する依存関係情報を追加したステアリングファイルを示します。 例 4-8 バージョン管理シンボルの作成、ステアリングファイル ver1 { global: foo; bar; local: *; }; ver2 { global: foo; } ver1; エラーと警告 スクリプトファイルを使用する場合は、バージョン定義とそのバージョン定義に関連 付けられるシンボルが一致する必要があります。不一致が見つかった場合は、リンカ から警告が生成されます。 ファイル名 コマンドラインオプション --symver_soname を使用すると、暗黙のシンボルバージョン 管理が有効になります。静的バインディングを行うためにシンボルのバージョン管理 を行う必要があり、指定されるバージョン番号に注意を払う必要がない場合は、この オプションを使用します。 シンボルにバージョンが定義されていない場合、リンクしているファイルの SONAME が 使用されます。 このオプションは、組み込みシンボルまたはスクリプトファイルと組み合わせて使用 することはできません。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 4-25 イメージのシンボルへのアクセス 4-26 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 第5章 スキャッタローディング記述ファイルの使用 本章では、ARM® リンカ armlink とスキャッタローディング記述ファイルを使用した複 雑イメージの作成方法を説明します。本章は以下のセクションから構成されています。 • スキャッタローディングについて(P. 5-2) • • • ARM DUI 0206GJ スキャッタローディング記述ファイルの正式な構文(P. 5-10) 領域アドレスとセクションアドレスの指定の例(P. 5-29) 等価なスキャッタローディング記述を使用した単純イメージの生成(P. 5-42) Copyright © 2002-2006 ARM Limited. All rights reserved. 5-1 スキャッタローディング記述ファイルの使用 5.1 スキャッタローディングについて イメージは領域と出力セクションから構成されます。イメージ内の領域には、異なる ロードアドレスと実行アドレスを使用することができます(「イメージ構造の指定」 (P. 3-2)参照)。 イメージのメモリマップを作成するには、以下に関する情報をリンカに渡す必要があ ります。 • 入力セクションを領域にグループ化する方法が記述された、グループ化に関する 情報 • メモリマップ内にイメージ領域を配置するアドレスが記述された、配置に関する 情報 スキャッタローディングを使用することで、リンカに渡すイメージのメモリマップを テキスト形式の記述ファイルによって指定できます。スキャッタローディングでは、イ メージを構成するコンポーネントのグループ化と配置を完全に制御できます。ス キャッタローディングは単純イメージにも使用できますが、一般的にはメモリマップ が複雑なイメージ、つまりロード時と実行時に複数の領域がメモリマップ内に分散す るイメージのみに使用されます。 このセクションでは、以下の内容について説明します。 • スキャッタローディング用に定義されるシンボル • スタックとヒープの指定(P. 5-4) • • • • 5-2 スキャッタローディングが使用される状況(P. 5-5) スキャッタローディングのコマンドラインオプション(P. 5-6) メモリマップが単純なイメージ(P. 5-6) メモリマップが複雑なイメージ(P. 5-8) Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 5.1.1 スキャッタローディング用に定義されるシンボル リンカは、スキャッタローディング記述ファイルを使用してイメージを作成するとき に、いくつかの領域に関連したシンボルを作成します。これらのシンボルについては、 「領域関連シンボル」(P. 4-3)を参照して下さい。これらの特殊なシンボルは、コード によって参照される場合にのみ作成されます。 未定義のシンボル 標準の設定では、スキャッタローディング記述ファイルを使用する場合は、以下のシ ンボルは定義されません。 • Image$$RW$$Base • Image$$RW$$Limit • Image$$RO$$Base • Image$$RO$$Limit • Image$$ZI$$Base • Image$$ZI$$Limit __user_initial_stackheap() の標準の設定の実装では、Image$$ZI$$Limit の値を使用し ます。標準の設定ではこのシンボルが定義されないため、__user_initial_stackheap() を再実装してヒープ領域の開始位置とスタック領域の最上部の値を定義する必要があ ります。ただし、手動で __user_initial_stackheap() を再実装することなく、C ライブ ラリに用意されている代替の実装を使用することもできます(「スタックとヒープの指 定」参照)。 注 __user_initial_stackheap() を再実装すると、すべてのライブラリ実装がオーバーライ ドされます。 スキャッタローディング記述ファイルを使用する場合、特別な領域名の指定がなく __user_initial_stackheap() が再実装されないとき場合にはライブラリから以下のエ ラーメッセージが生成されます。 Error: L6915E: Library reports error: scatter-load file declares no heap or stac k regions and __user_initial_stackheap is not defined. 詳細については、以下について説明した章を参照して下さい。 ARM DUI 0206GJ • RealView Compilation Tools v3.0 Compiler and Libraries Guide の C および C++ のラ イブラリに関する章(ライブラリのメモリモデルの詳細) • RealView Compilation Tools v3.0 Developer Guide の組み込みソフトウェア開発に関 する章 Copyright © 2002-2006 ARM Limited. All rights reserved. 5-3 スキャッタローディング記述ファイルの使用 5.1.2 スタックとヒープの指定 ARM C ライブラリには __user_initial_stackheap() に代わる実装があり、スキャッタ ローディング記述ファイルの情報から適切な実装が自動的に選択されます。 2 つの領域によるメモリモデルを選択するには、スキャッタローディング記述ファイ ルに ARM_LIB_HEAP および ARM_LIB_STACK という名前の特殊な実行領域 2 つを定義しま す。これらの領域には EMPTY 属性があります。そのため、ライブラリでは、以下のシ ンボルの値を使用する、__user_initial_stackheap() の標準の設定ではない実装が選 択されます。 • Image$$ARM_LIB_STACK$$Base • Image$$ARM_LIB_STACK$$ZI$$Limit • Image$$ARM_LIB_HEAP$$Base • Image$$ARM_LIB_HEAP$$ZI$$Limit ARM_LIB_STACK 領域と ARM_LIB_HEAP 領域は、それぞれ 1 つのみ指定できます。その際、 サイズを割り当てる必要があります。以下に例を示します。 ARM_LIB_HEAP 0x20100000 EMPTY 0x100000-0x8000 ARM_LIB_STACK 0x20200000 EMPTY -0x8000 ; ; ; ; ; Heap starts at 1MB and grows upwards Stack space starts at the end of the 2MB of RAM And grows downwards for 32KB EMPTY 属性が指定された ARM_LIB_STACKHEAP という単一の実行領域を定義することによ り、__user_initial_stackheap() でスタックとヒープの結合領域を使用できます。その 結果 __user_initial_stackheap() では、シンボル Image$$ARM_LIB_HEAP$$Base および Image$$ARM_LIB_STACK$$ZI$$Limit の値が使用されます。 注 __user_initial_stackheap() を再実装すると、すべてのライブラリ実装がオーバーライ ドされます。 5-4 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 5.1.3 スキャッタローディングが使用される状況 リンカへのコマンドラインオプションを使用することでデータとコードの配置をある 程度制御できますが、配置を完全に制御するには、コマンドラインから入力可能な指 示よりもさらに詳細な指示を必要とします。以下に、スキャッタローディング記述ファ イルが必要である(または有効である)ケースを挙げます。 メモリマップが複雑な場合 数多くの異なるメモリエリアに配置しなければならないコードとデータ には、どのセクションをどのメモリ空間に配置するかの詳細な指示が必 要となります。 メモリタイプが異なる場合 多くのシステムには、フラッシュ、ROM、SDRAM、高速 SRAM など、 さまざまな物理メモリデバイスが組み込まれています。スキャッタロー ディング記述ファイルによって、コードとデータを最も適切なメモリタ イプに対応付けることができます。例えば、割り込みコードを高速 SRAM に配置して割り込み応答時間を向上させ、あまり使用されないコンフィ ギュレーション情報はそれよりも遅いフラッシュメモリに配置すると いったことが考えられます。 メモリマップされた I/O を使用する場合 スキャッタローディング記述ファイルを使用して、データセクションを メモリマップ内の正確なアドレスに配置して、メモリマップされたペリ フェラルにアクセスできます。 関数の位置を固定する場合 ある関数を含むアプリケーションが修正され、再コンパイルされた場合 でも、その関数をメモリ内の同じ位置に配置しておくことができます。 ヒープとスタックの識別にシンボルを使用する場合 アプリケーションをリンクするときのヒープとスタックの位置を示すシ ンボルを定義できます。 このように、組み込みシステムでは ROM、RAM、およびメモリマップされた I/O が使 用されるため、組み込みシステムの実装ではほとんどの場合にスキャッタローディン グが必要となります。 注 Cortex-M3 プロセッサ用にコンパイルを行っている場合、このプロセッサのメモリ マップは固定されているので、スキャッタローディング記述ファイルでスタックと ヒープの両方を定義できます。この例は、メインサンプルディレクトリ install_directory\RVDS\Examples に Cortex-M3.scat という名前で収録されています。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-5 スキャッタローディング記述ファイルの使用 5.1.4 スキャッタローディングのコマンドラインオプション 以下に、スキャッタローディングを使用するための armlink コマンドラインオプション を示します。 --scatter description_file このコマンドは、description_file に記述されているとおりにイメージのメモリマップ 「ス を構成するようにリンカに指示します。記述ファイルのフォーマットについては、 キャッタローディング記述ファイルの正式な構文」(P. 5-10)を参照して下さい。 スキャッタローディング記述ファイルのその他の情報については、以下を参照して下 さい。 5.1.5 • 領域アドレスとセクションアドレスの指定の例(P. 5-29) • 等価なスキャッタローディング記述を使用した単純イメージの生成(P. 5-42) • RealView Compilation Tools v3.0 Developer Guide の組み込みソフトウェアの開発方 法に関する章 メモリマップが単純なイメージ P. 5-7 図 5-1 に示すスキャッタローディングの記述では、オブジェクトファイルのセグ メントが、P. 5-7 図 5-2 に示すマップに従ってメモリにロードされます。領域の最大サ イズを指定するかどうかは任意ですが、指定することによってその領域が境界から オーバフローしていないかどうかをチェックできます。 この例では、リンカに渡すコマンドラインオプションとして --ro-base 0x0 および --rw-base 0x10000 と指定しても同じ結果を得ることができます。 5-6 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 Start address for load region Name of load region Name of first exec region Maximum size of load region Start address for exec region LOAD_ROM 0x0000 0x8000 { Name of second exec region EXEC_ROM 0x0000 0x8000 { * (+RO) } Start of second exec region RAM 0x10000 0x6000 { * (+RW,+ZI) } } Maximum size of this exec region Place all code and RO data into this exec region Maximum size of this exec region Place all RW and ZI data into this exec region 図 5-1 スキャッタローディング記述ファイルの単純メモリマップ Load view Execution view Zero fill ZI section RW section Copy / decompress SRAM 0x10000 0x8000 RW section RO section 0x16000 RO section ROM 0x0000 図 5-2 スキャッタローディングを行った単純メモリマップ ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-7 スキャッタローディング記述ファイルの使用 5.1.6 メモリマップが複雑なイメージ 図 5-3 に示すスキャッタローディングの記述では、program1.o ファイルと program2.o ファイルに含まれるセグメントが、P. 5-9 図 5-4 に示すマップに従ってメモリにロード されます。 P. 5-7 図 5-2 に示した単純なメモリマップとは異なり、基本的なコマンドラインオプ ションだけではこのマップを適用するようにリンカに指示することができません。 注意 図 5-3 に示すスキャッタローディングの記述では、program1.o と program2.o のみの コードおよびデータの位置を指定しています。したがって、例えば program3.o という 別のモジュールをリンクさせるときにこの記述ファイルを使用しても、program3.o の コードとデータの位置は指定されません。 コードとデータの配置をかなり厳密に指定する必要がある箇所を除く、コードとデー タは * または .ANY 指定子を使用して配置することをお勧めします( 「領域を配置するア ドレスの固定」(P. 5-32)参照)。 LOAD_ROM_1 0x0000 { EXEC_ROM_1 0x0000 { program1.o (+RO) } } DRAM 0x18000 0x8000 { program1.o (+RW,+ZI) } LOAD_ROM_2 0x4000 { EXEC_ROM_2 0x4000 { program2.o (+RO) } } SRAM 0x8000 0x8000 { program2.o (+RW,+ZI) } Start address for first load region Start address for first exec region Place all code and RO data from program1.o into this exec region Start address for this exec region Maximum size of this exec region Place all RW and ZI data from program1.o into this exec region Start address for second load region Place all code and RO data from program2.o into this exec region Place all RW and ZI data from program2.o into this exec region 図 5-3 スキャッタローディング記述ファイルの複雑メモリマップ 5-8 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 Load view Execution view Zero fill ZI section#2 RW section#1 0x20000 DRAM 0x18000 0x10000 ZI section#1 RW section#2 RW section#2 0x4000 RO section#2 RO section#2 0x0000 0x08000 ROM2 ROM1 RW section#1 RO section#1 SRAM RO section#1 0x00000 図 5-4 スキャッタローディングを行った複雑メモリマップ ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-9 スキャッタローディング記述ファイルの使用 5.2 スキャッタローディング記述ファイルの正式な構文 スキャッタローディング記述ファイルは、ターゲットの組み込み製品のメモリマップ をリンカに通知するテキストファイルです。リンカをコマンドラインから使用する場 合には、この記述ファイルのファイル拡張子に意味はありません。スキャッタローディ ング記述ファイルを使用すると、以下を指定できます。 • 各ロード領域のロードアドレスと最大サイズ • 各ロード領域の属性 • 各ロード領域から導出される実行領域 • 各実行領域の実行アドレスと最大サイズ • 各実行領域の入力セクション 記述ファイルのフォーマットには、ロード領域、実行領域、および入力セクションの 階層が反映されます。 注 領域に対する入力セクションの割り当ては、スキャッタローディング記述ファイルに 記載されている選択パターンの順序とまったく関係ありません。選択パターンと、ファ イル/セクションの名前またはセクション属性との間で最適な組み合わせが使用されま (P. 5-25)を参照して下さい。 す。詳細については、「複数のマッチングの解決」 このセクションでは、以下の内容について説明します。 • BNF 記法と構文(P. 5-11) • • • • • • 5-10 スキャッタローディング記述ファイルに使用される構文の概要(P. 5-12) ロード領域の記述(P. 5-14) 実行領域の記述(P. 5-16) 入力セクションの記述(P. 5-20) 複数のマッチングの解決(P. 5-25) パス名の解決(P. 5-28) Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 5.2.1 BNF 記法と構文 表 5-1 は、形式言語の記述に使用されるバッカスナウア記法(BNF)のシンボルを示し ています。 表 5-1 BNF の構文 シンボル 説明 " 二重引用符は、通常は BNF 構文の一部である文字が定義の中でリテラ ル文字として使用されることを示す場合に使用します。例えば、定義 B"+"C は、パターン B+C のみに置き換えられます。定義 B+C は、パター ン BC、BBC、BBBC などに置き換えられます。 A ::= B A を B として定義します。例えば、A::= B"+" | C は、A が B+ または C のいずれかと等価であることを意味します。::= は、そのコンポーネン トにおける上位の構成を定義するために使用されます。各コンポーネ ントには、さらに単純なコンポーネントに関連してそれを定義する ::= 定義を使用することもできます。例えば、A::= B と B::= C | D は、 A の定義がパターン C または D に等しいことを意味します。 [A] 任意の要素 A を表します。例えば、A::= B[C]D は、定義 A が BD または BCD として解釈されます。 A+ 要素 A が 1 つ以上あることを表します。例えば、A::= B+ は、定義 A が B、BB、BBB などとして解釈されます。 ARM DUI 0206GJ A* 要素 A が 0 個以上あることを表します。 A|B 要素 A または B のどちらかが出現する可能性があり、両方出現するこ とはないことを意味します。 (A B) 要素 A および B が一緒にグループ化されることを意味します。このシ ンボルは、| 演算子が使用される場合、または複雑なパターンが繰り 返される場合に特に便利です。例えば、A::=(B C)+ (D | E) は、定義 A が BCD、BCE、BCBCD、BCBCE、BCBCBCD、BCBCBCE のいずれとしても解釈でき ることを意味します。 Copyright © 2002-2006 ARM Limited. All rights reserved. 5-11 スキャッタローディング記述ファイルの使用 5.2.2 スキャッタローディング記述ファイルに使用される構文の概要 注 このセクションの BNF の定義では、読みやすくするために改行とスペースが挿入され ています。スキャッタローディングの定義に改行やスペースを挿入する必要はなく、 ファイル内に存在している場合は無視されます。 scatter_description は、1 つ以上の load_region_description パターンとして定義され ます。 Scatter_description ::= load_region_description+ load_region_description は、ロード領域の名前の後に、属性またはサイズ指定子が任 意で続き、さらに 1 つ以上の実行領域の記述が続くものとして定義されます。以下に 例を示します。 load_region_description ::= load_region_name (base_address | ("+" offset)) [attributes] [max_size] "{" execution_region_description+ "}" execution_region_description は、実行領域の名前とベースアドレスの指定の後に、属 性またはサイズ指定子が任意で続き、さらに 1 つ以上の入力セクションの記述が続く ものとして定義されます。以下に例を示します。 execution_region_description ::= exec_region_name (base_address | "+" offset) [attribute_list] [max_size | "–" length] "{" input_section_description* "}" input_section_description は、ソースモジュールセレクタパターンの後に任意で入力 セクションのセレクタが続くものとして定義されます。以下に例を示します。 input_section_selector ::= ("+" input_section_attr | input_section_pattern | input_symbol_pattern) input_section_description ::= module_select_pattern 5-12 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 ["(" ("+" input_section_attr | input_section_pattern | input_symbol_pattern) ("," "+" input_section_attr | "," input_section_pattern | "," input_symbol_pattern)* ")"] P. 5-13 図 5-5は、典型的なスキャッタローディング記述ファイルのコンポーネントを示 しています。 Scatter description Load region description LOAD_ROM_1 0x0000 { Execution region description EXEC_ROM_1 0x0000 { program1.o (+RO) } } Input section description Execution region description DRAM 0x18000 0x8000 { program1.o (+RW,+ZI) } Input section description Load region description LOAD_ROM_2 0x4000 { Execution region description EXEC_ROM_2 0x4000 { program2.o (+RO) } } Input section description Execution region description SRAM 0x8000 0x8000 { program2.o (+RW,+ZI) } Module selector pattern Input section description Input section attributes 図 5-5 スキャッタローディング記述ファイルの定義のコンポーネント ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-13 スキャッタローディング記述ファイルの使用 5.2.3 ロード領域の記述 ロード領域には、以下の内容が含まれます。 • 名前(各ロード領域を識別するためにリンカによって使用されます) • ベースアドレス(ロードビューにおけるコードとデータの開始アドレスです) • 属性(任意) • 最大サイズ(任意) • 実行領域のリスト(これによって実行ビューにおけるモジュールのタイプと位置 が識別されます) 図 5-6 は、典型的なロード領域の記述に含まれるコンポーネントを示しています。 Load region description LOAD_ROM_1 0x0000 { A load region description contains one or more execution region descriptions EXEC_ROM_1 0x0000 { program1.o (+RO) } } DRAM 0x18000 0x8000 { program1.o (+RW,+ZI) } 図 5-6 ロード領域の記述に含まれるコンポーネント BNF での構文は以下のとおりです。 load_region_description ::= load_region_name (base_address | ("+" offset)) [attribute_list] [ max_size ] "{" execution_region_description+ "}" 5-14 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 各パラメータには以下の意味があります。 load_region_name 実行領域ごとに Load$$exec_region_name$$base シンボルが生 成されます。このシンボルには、実行領域のロードアドレスが 格納されます(「実行領域の記述」(P. 5-16)参照)。ただし、 load_region_name は各領域を識別するためのみに使用されま す。Load$$region_name シンボルの生成には使用されません。 注 デバッガは領域をそれぞれのロードアドレスにロードする必要 があるため、デバッガ用に作成されるイメージには、各領域に固 有のベースアドレスを指定する必要があります。ロード領域のア ドレスが重複していると、イメージの一部が上書きされます。 ただし、ローダまたはオペレーティングシステムでは、重複し ている位置に依存しない領域を正しくロードできます。1 つ以上 の位置に依存しない領域が、自動的に異なるアドレスに移動さ れます。 base_address 領域内のオブジェクトがリンクされるアドレスを指定します。 base_address はワード境界で整列される必要があります。 +offset 前のロード領域の終わりから offset バイト離れたベースアドレ スを指定します。offset には 4 で割った余りが 0 になる値を指定 する必要があります。この領域が最初のロード領域である場合、 +offset は、ベースアドレスがゼロから offset バイトの位置で開 始されることを意味します。 attribute_list 以下の属性を使用して、ロード領域の内容の特性を指定します。 ABSOLUTE 絶対アドレス PI 位置非依存 RELOC 再配置可能 OVERLAY オーバーレイ NOCOMPRESS 無圧縮 属性 ABSOLUTE、PI、RELOC、OVERLAY はいずれか 1 つしか指定でき ません。標準の設定のロード領域の属性は ABSOLUTE です。 PI、RELOC、OVERLAY のいずれかの属性を持つロード領域には、重 複するアドレス範囲を指定できます。ABSOLUTE 属性のロード領域 に重複するアドレス範囲が指定されていると、エラーが生成され ます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-15 スキャッタローディング記述ファイルの使用 OVERLAY キーワードを使用すると、同じアドレスに複数の実行領 域を指定できます。ARM は、RVCT ではオーバーレイ機能をサ ポートしていません。同じアドレスにある複数の実行領域を使用 するには、ユーザ独自のオーバーレイマネージャを使用する必要 があります。 RW デ ー タ圧縮は標準の設定でイネーブルになっています。 NOCOMPRESS キーワードを使用すると、最終イメージでロード領域 が圧縮されません。 max_size ロ ー ド 領 域 の 最 大 サ イ ズ を 指 定 し ま す。オ プ シ ョ ン と し て max_size の値が指定されている場合、その領域に max_size バ イトを超えるサイズが割り当てられていると、armlink によっ てエラーが生成されます。 execution_region_description 実行領域の名前、アドレス、および内容を指定します。詳細につ いては、「実行領域の記述」(P. 5-16)を参照して下さい。 5.2.4 実行領域の記述 実行領域には、以下の内容が含まれます。 • 名前 • ベースアドレス(絶対アドレスまたは相対アドレス) • 最大サイズ(任意) • 実行領域の特性を指定する属性 • 入力セクションの 1 つ以上の記述(実行領域内に配置されるモジュール) 図 5-7 は、典型的な実行領域の記述に含まれるコンポーネントを示しています。 EXEC_ROM_1 0x0000 { program1.o (+RO) } Execution region description An execution region description contains one or more input section descriptions 図 5-7 実行領域の記述に含まれるコンポーネント BNF での構文は以下のとおりです。 execution_region_description ::= exec_region_name (base_address | "+" offset) [attribute_list] [max_size | "–" length] "{" input_section_description* "}" 5-16 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 各パラメータには以下の意味があります。 exec_region_name base_address 実行領域の名前を指定します。 領域内のオブジェクトがリンクされるアドレスを指定します。 base_address はワード境界で整列される必要があります。 +offset 前の実行領域の終わりから offset バイト離れたベースアドレス を指定します。offset には 4 で割った余りが 0 になる値を指定す る必要があります。 前の実行領域がない場合(つまり、ロード領域内においてそれが 最初の実行領域である場合)には、+offset は、ロード領域のベー スから offset バイト離れた位置でベースアドレスが開始される ことを意味します。 +offset の形式が使用され、そのアドレスを含むロード領域の属 性が RELOC である場合、実行領域は RELOC 属性を継承します。た だし、固定の base_address が使用される場合は、その後に offset が出現しても RELOC 属性は継承されません。 attribute_list ARM DUI 0206GJ 以下の属性を使用して、実行領域の内容の特性を指定します。 ABSOLUTE 絶対アドレス。領域の実行アドレスはベース 指定子で指定されます。 PI 位置非依存 OVERLAY オーバーレイ FIXED 固定アドレス。領域のロードアドレスと実行 アドレスの両方がベース指定子によって指 定されます(その領域はルート領域となりま す)。詳細については、 「ルート実行領域の作 成」(P. 5-30)を参照して下さい。ベース指 定子には、絶対ベースアドレスまたはオフ セット +0 を指定する必要があります。 EMPTY このオプションを指定すると、通常はヒープ またはスタックのために、指定された長さの 空メモリブロックが実行領域内に確保され 「空き領域の予約」 ます。詳細については、 (P. 5-37)を参照して下さい。 Copyright © 2002-2006 ARM Limited. All rights reserved. 5-17 スキャッタローディング記述ファイルの使用 PADVALUE パッドする値を定義します。PADVALUE を指 定する場合、以下のように値を指定する必要 があります。 EXEC 0x10000 PADVALUE 0xffffffff EMPTY ZEROPAD 0x2000 この結果、0xffffffff でパディングサイズ 0x2000 の領域が作成されます。 PADVALUE のサイズは 1 ワードである必要が あります。ロード領域の PADVALUE 属性は無 視されます。 ZEROPAD ゼロで初期化されたセクションが、ゼロのブ ロックとして ELF ファイルに書き込まれま す。このオプションを指定した場合、実行時 にセクションにゼロを書き込む必要があり ません。 シミュレーションなどの特定の状況では、ゼ ロを書き込むループに時間を費やすよりも、 このオプションを使用するのが適切です。 NOCOMPRESS 圧縮しません。 UNINIT ゼロで初期化することを禁止します。 max_size オプションとして数値を指定すると、領域に max_size バイトを超 えるサイズが割り当てられている場合にエラーが生成されます。 -length 長さに負の値が指定されている場合は、base_address がその領域 の終了アドレスとして使用されます。一般的には EMPTY と組み合 わせ、メモリ内で下向きに成長するスタックを表現します。詳細 「空き領域の予約」(P. 5-37)を参照して下さい。 については、 input_section_description 入力セクションの内容を指定します。詳細については、「入力セ クションの記述」(P. 5-20)を参照して下さい。 5-18 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 実行領域の特性を指定するときは、以下に注意して下さい。 • 属性 PI、OVERLAY、FIXED、ABSOLUTE はいずれか 1 つしか指定できません。PI、 FIXED、OVERLAY のいずれか 1 つの属性が指定されている場合を除き、ABSOLUTE が 実行領域の標準の設定の属性として使用されます。 • ベース指定子の形式として +offset を使用している実行領域は、前の実行領域の 属性(この領域がロード領域の最初の実行領域である場合はロード領域の属性) を継承するか、ABSOLUTE 属性が使用されます。 • ルート実行領域に限り、ZEROPAD 属性を使用してゼロで初期化できます。ルート 以外の実行領域で ZEROPAD 属性を使用すると、警告が生成され、属性が無視され ます。 • 実行領域には、属性 RELOC を明示的に指定できません。実行領域は、ロード領域 から属性を継承することでのみ RELOC 属性を適用できます。 • ベース指定子の形式として +offset を使用する実行領域には、その領域に固有の 属性を指定することはできません(ただし、継承をオーバライドする ABSOLUTE 属性は除きます)。開始位置を変更せずに領域に ABSOLUTE 属性を設定するには、 +0 ABSOLUTE を使用します。 • PI または OVERLAY 属性を指定した実行領域(または、RELOC 属性を継承している 実行領域)では、アドレス範囲を重複させることができます。ABSOLUTE および FIXED 属性の実行領域に、重複するアドレス範囲が指定されていると、エラーが 生成されます。 • RW データ圧縮は標準の設定ではイネーブルになっています。NOCOMPRESS キー ワードを使用すると、最終イメージで実行領域が圧縮されません。 • UNINIT を指定すると、実行領域の ZI 出力セクションがゼロで初期化されません。 このキーワードを使用して作成した実行領域には、初期化されていないデータま たはメモリマップされた I/O が含まれます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-19 スキャッタローディング記述ファイルの使用 5.2.5 入力セクションの記述 入力セクションの記述は、以下の名前や属性によって入力セクションを識別するパ ターンを示します。 • モジュールの名前(オブジェクトファイルの名前、ライブラリメンバの名前、ま たはライブラリファイルの名前)。モジュールの名前にはワイルドカード文字を 使用できます。 • 入力セクションの名前、または READ-ONLY や CODE などの入力セクションの属性。 • シンボル名。 図 5-8 は、典型的な入力セクションの記述に含まれるコンポーネントを示しています。 program2.o (+RO) Module select pattern Input section description Input section attribute 図 5-8 入力セクションの記述に含まれるコンポーネント BNF での構文は以下のとおりです。 input_section_description ::= module_select_pattern ["(" ("+" input_section_attr | input_section_pattern | input_symbol_pattern) ("," "+" input_section_attr | "," input_section_pattern | "," input_symbol_pattern)* ")"] 5-20 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 各パラメータには以下の意味があります。 module_select_pattern リテラルテキストで作成されるパターンです。ワイルドカード文字 * は ゼロ個以上の文字に対応し、? は任意の 1 文字に対応します。 ファイル名の大文字と小文字が区別されるホスト上であっても、この対 応付けが行われる場合には大文字と小文字は区別されません。 すべてのオブジェクトに対応させる場合は、*.o を使用します。すべての オブジェクトファイルおよびライブラリに対応させる場合は、* を使用 します。 module_select_pattern が以下のいずれかと一致する場合、入力セクショ ンはモジュールセレクタパターンと一致します。 • そのセクションを含むオブジェクトファイルの名前。 • ライブラリメンバの名前(先頭のパス名を除く)。 • セクションが保存されていたライブラリのフルネーム(パス名を含 む) 。名前にスペースが含まれている場合は、検索を容易にするため にワイルドカードを使用して下さい。例えば、C:\lib dir\libname.lib とマッチングを行う場合には *libname.lib を使用します。 特殊なモジュールセレクタパターン .ANY を使用すると、入力セクション のペアレントモジュールを考慮することなく、入力セクションを実行領 域に割り当てることができます。.ANY は、実行領域をドントケア(Don't care)に設定する場合に使用します。 注 • module_select_pattern と、少なくとも 1 つの input_section_attr または input_section_pattern の両方に一致する入力セクション のみが実行領域にインクルードされます。 (+ input_section_attr) と (input_section_pattern) が省略されて いる場合は、標準の設定では +RO が使用されます。 • ARM DUI 0206GJ コンパイラによって生成されるか、または ARM ライブラリコード によって使用される入力セクションの名前を何らかの前提として 使用しないで下さい。これらの名前は、異なるコンパイラオプショ ンが使用される場合など、コンパイル毎に変わる可能性がありま す。また、コンパイラによって使用されるセクション命名規則は、 リリース間で異なる場合があります。 Copyright © 2002-2006 ARM Limited. All rights reserved. 5-21 スキャッタローディング記述ファイルの使用 input_section_attr 入力セクションの属性とのマッチングが行われる属性セレクタです。各 input_section_attr の前に + を指定します。 入力セクションの名前とマッチングが行われるパターンを指定するに は、その名前の先頭に + を付ける必要があります。+ の直前のコンマは省 略できます。 このセレクタでは大文字と小文字が区別されません。以下のセレクタが 認識されます。 • RO-CODE • RO-DATA • RO (RO-CODE と RO-DATA の両方が選択されます) • RW-DATA • RW-CODE • RW(RW-CODE と RW-DATA の両方が選択されます) • ZI • ENTRY (ENTRY ポイントを含むセクション) 以下の同義語が認識されます。 • RO-CODE の代わりに CODE • RO-DATA の代わりに CONST • RO の代わりに TEXT • RW の代わりに DATA • ZI の代わりに BSS 以下の擬似属性が認識されます。 • FIRST • LAST 実行領域内の配置順序が重要な場合(例えば、特定の入力セクションを 領域の最初に配置する必要がある場合、およびチェックサムを含む入力 セクションを最後に配置する必要がある場合など)には、FIRST と LAST を使用して、最初のセクションと最後のセクションをマークできます。 input_section_attr の最初に FIRST または LAST が指定されていると、そ こでリストが終了します。 特殊なモジュールセレクタパターン .ANY を使用すると、入力セクション の親モジュールを考慮することなく、入力セクションを実行領域に割り 当てることができます。1 つ以上の .ANY パターンを使用することによ り、実行領域をドントケアに設定できます。ほとんどの場合、1 つの .ANY を使用しても、* モジュールセレクタを使用しても、同じ結果が得られ ます。 5-22 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 スキャッタローディング記述ファイル内で、* セレクタを 2 つ使用する ことはできません。ただし、これに変更を加え *A と *B のようにしたセ レクタは 2 つ使用できます。また、.ANY セレクタと * モジュールセレク タを 1 つずつ組み合わせて使用することもできます。* モジュールセレ クタは .ANY に優先されます。* セレクタを含むファイルの部分が削除さ れると、.ANY セレクタが有効になります。 .ANY モジュールセレクタパターンを持つ入力セクションの記述は、他の すべての(.ANY が使用されていない)入力セクションの記述が解決され た後に解決されます。実行領域に割り当てられていないすべてのセク ションは、.ANY 領域に割り当てられます。 複数の .ANY パターンが存在している場合、リンカは実行領域に割り当て られていないセクションのうち、サイズが最大のセクションを取得し、 それを最も限定的で空き領域が十分ある .ANY 実行領域に割り当てます。 armlink によってこの選択が行われるときは、.ANY(.text) は .ANY(+RO) よりも限定的だと判断されます。 複数の実行領域が等しく限定的である場合、空き領域が最も大きい実行 領域にセクションが割り当てられます。 以下に例を示します。 • 2 つの実行領域が等しく限定的であり、1 つはサイズ制限が 0x2000、 もう 1 つは制限がない場合、後者の無制限の .ANY 領域にすべての セクションが割り当てられます。 • 2 つの実行領域が等しく限定的であり、1 つはサイズ制限が 0x2000、 もう 1 つはサイズ制限が 0x3000 である場合、配置されるセクショ ンはまず、サイズ制限が 0x3000 である後者の .ANY 領域に、残りサ イズが 0x2000 になるまで割り当てられていきます。その後は、両 方の .ANY 実行領域に交互にセクションが割り当てられます。 input_section_pattern 大文字と小文字の区別なく、入力セクションの名前とのマッチングが行 われるパターンです。リテラルテキストで構成されます。ワイルドカー ド文字 * はゼロ個以上の文字に対応し、? は任意の 1 文字に対応します。 注 複数の input_section_pattern を使用する場合、曖昧エラーを避けるため、 他の実行領域とパターンが重複しないようにします。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-23 スキャッタローディング記述ファイルの使用 input_symbol_pattern 入力セクションによって定義されているグローバルシンボルの名前を使 用して、そのセクションを選択します。このオプションを使用すると、 部分的にリンクされたオブジェクトから、同名のセクションを個別に選 択できます。 :gdef: 接頭文字でグローバルシンボルパターンとセクションパターンを 区 別 し ま す。例 えば、mysym を定義するセクションを選択するには :gdef:mysym を使用します。以下に、グローバルシンボル mysym1 を定義 するセクションと、グローバルシンボル mysym2 を含むセクションが ExecReg1 に存在する記述ファイルの例を示します。 LoadRegion 0x8000 { ExecReg1 +0 { *(:gdef:mysym1) *(:gdef:mysym2) } . . } 注 複数の input_symbol_pattern を使用する場合、曖昧エラーを避けるため、 他の実行領域とパターンが重複しないようにします。 5-24 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 5.2.6 複数のマッチングの解決 あるセクションと複数の実行領域とのマッチングが行われる場合、それらのマッチン グは以下のように解決されます。一意の一致が検出されない場合は、そのスキャッタ ローディングの記述の処理が中止されます。各セクションは、module_select_pattern と input_section_selector によって選択されます。 例えば、module_select_pattern は以下のように指定できます。 • * は、任意のモジュールまたはライブラリと一致します。 • *.o は任意のオブジェクトモジュールと一致します。 • math.o は math.o モジュールと一致します。 • *armlib* は、ARM が提供するすべての C ライブラリと一致します。 • *math.lib は、math.lib で終わる任意のライブラリパスと一致します (例:C:\apps\lib\math\satmath.lib)。 例えば、input_section_selector は以下のように指定できます。 • +RO は、すべての RO コードとすべての RO データとマッチングが行われる入力 セクション属性です。 • +RW,+ZI は、すべての RW コード、RW データ、および ZI データとマッチングが 行われる入力セクション属性です。 • BLOCK_42 は、BLOCK_42 と命名されたアセンブリファイルのエリアとマッチングが 行われる入力セクションパターンです。 注 コンパイラは、.text、.data、.constdata、.bss などの入力セクションパターン によって識別可能なエリアを生成します。ただしこれらの名前は今後のバージョ ンで変更される可能性があるため、なるべく使用しないで下さい。 C または C++ のファイルに含まれる特定の関数または extern データとのマッチ ングを行う必要がある場合には、以下のどちらかを行って下さい。 — その関数またはデータを別のモジュール内にコンパイルし、そのモジュー ルのオブジェクト名とマッチングを行う。 — #pragma arm section または __attribute__ を使用して、対象のコードまた はデータを含むセクションの名前を指定する。プラグマの詳細については、 RealView Compilation Tools v3.0 Compiler and Libraries Guide の ARM コンパ イラリファレンスの章を参照して下さい。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-25 スキャッタローディング記述ファイルの使用 複数のマッチングを記述するには以下の変数を使用します。 • m1 と m2 は、モジュールセレクタパターンを表します。 • s1 と s2 は入力セクションセレクタを表します。 複 数 の 一 致 が あ る 場 合、入 力 セ ク シ ョ ン を 割 り 当 て る 領 域 を、最 も 限 定 的 な module_select_pattern と input_section_selector の組み合わせに基づいて決定 します。 例えば、入力セクション A が実行領域 R1 の m1,s1 と一致し、さらに実行領域 R2 の m2,s2 とも一致する場合は、以下のように処理されます。 • m1,s1 が m2,s2 よりも限定的である場合、A は R1 に割り当てられます。 • m2,s2 が m1,s1 よりも限定的である場合、A は R2 に割り当てられます。 • m1,s1 が m2,s2 よりも限定的ではなく、m2,s2 が m1,s1 よりも限定的ではない場合、 そのスキャッタローディングの記述にエラーがあると診断されます。 armlink が module_select_pattern と input_section_selector の最も限定的な組み合わ せを決定するために使用するシーケンスは以下のとおりです。 1. モジュールセレクタパターンの場合: テキストストリング m1 がパターン m2 と一致し、テキストストリング m2 がパ ターン m1 と一致しない場合には、m1 は m2 よりも限定的です。 2. 5-26 入力セクションセレクタの場合: • s1 と s2 が両方ともセクション名と一致するパターンである場合には、モ ジュールセレクタパターンと同じ定義が使用されます。 • s1 と s2 の一方が入力セクション名と一致し、他方が入力セクション属性と 一致する場合、s1 と s2 は規則がなく、その記述にエラーがあると診断され ます。 • s1 と s2 の両方が入力セクション属性に一致する場合、s1 が s2 よりも限定 的かどうかは、以下の関係によって決定されます。 — ENTRY は、RO-CODE、RO-DATA、RW-CODE、RW-DATA のどれよりも限定的 である。 — RO-CODE は RO よりも限定的である。 — RO-DATA は RO よりも限定的である。 — RW-CODE は RW よりも限定的である。 — RW-DATA は RW よりも限定的である。 — セクション属性間には上記以外の(s1 が s2 よりも限定的である)関 係はありません。 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 3. module_select_pattern, input_section_selector の対において、以下のいずれか が真である場合にのみ、m1,s1 は m2,s2 よりも限定的です。 • s1 がリテラルの入力セクション名(つまり、パターン文字が含まれていな い名前)であり、s2 が +ENTRY 以外の入力セクション属性と一致する。 • m1 が m2 よりも限定的である。 • s1 が s2 よりも限定的である。 このマッチング方式による影響は以下のとおりです。 ARM DUI 0206GJ • 記述は、ファイル内に書かれた順序に依存しません。 • 通常、オブジェクトの記述がより限定的であるほど、それが保持する入力セク ションの記述がより限定的になります。 • input_section_selector は以下の場合にのみチェックされます。 — オブジェクトの選択が確定されない場合。 — 一方のセレクタが入力セクションの名前を具体的に指定し、他方が属性に よって選択する場合。この場合、明示的な入力セクションの名前は、ENTRY を除くどの属性よりも限定的であり、1 つのオブジェクトから 1 つの入力 セクションのみが選択されます。このことは、入力セクションの名前に関 連するオブジェクトのセレクタが、属性のセレクタより限定的ではない場 合にも当てはまります。 Copyright © 2002-2006 ARM Limited. All rights reserved. 5-27 スキャッタローディング記述ファイルの使用 例 5-1 は、複数の実行領域とパターンのマッチングを示しています。 例 5-1 複数の実行領域とパターンのマッチング LR_1 0x040000 { ER_ROM 0x040000 { application.o (+ENTRY) } ER_RAM1 0x048000 { application.o (+RO-CODE) } ER_RAM2 0x050000 { application.o (+RO-DATA) } ER_RAM3 0x060000 { application.o (+RW) } ER_RAM4 +0 { *.o (+RO, +RW, +ZI) } } 5.2.7 ; ; ; ; The startup exec region address is the same as the load address. The section containing the entry point from the object is placed here. ; Other RO code from the object goes here ; The RO data goes here ; RW code and data go here ; Follows on from end of ER_R3 ; Everything except for application.o goes here パス名の解決 スキャッタローディング記述ファイルのワイルドカードパターンに対して、パス名内 に検出されるスラッシュとバックスラッシュの組み合わせとのマッチングが行われま す。パスを環境変数または複数のソースから取得した場合や、Windows、Sun Solaris、 Red Hat Linux プラットフォームで同一のスキャッタローディング記述ファイルを使用 する場合に、このマッチング方法が役立ちます。 注 Windows、Sun Solaris、Red Hat Linux のいずれのプラットフォームでも認識されるよう、 パス名にはスラッシュを使用することをお勧めします。 5-28 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 5.3 領域アドレスとセクションアドレスの指定の例 このセクションでは、スキャッタローディング記述ファイルを使用して、以下のこと を実行する方法を説明します。 • メモリマップにベニアを配置する。 • ルート実行領域を作成する。 • 領域を配置するアドレスを固定する。 • オーバーレイを使用して、セクションの配置やルート領域への割り当てを行う。 • EMPTY 属性を使用して、空のメモリブロックを予約する。 • ARM が提供するライブラリコードを配置する。 • プリプロセッシングディレクティブを使用する。 アドレスが固定しているデータおよび関数にアクセスする詳細については、RealView Compilation Tools v3.0 Developer Guide の組み込みソフトウェアの開発方法に関する章を 参照して下さい。 このセクションでは、以下の内容について説明します。 • スキャッタローディングの記述におけるベニア入力セクションの選択 • ルート実行領域の作成(P. 5-30) • • • • • • 5.3.1 領域を配置するアドレスの固定(P. 5-32) オーバーレイを使用したセクションの配置(P. 5-36) ルート領域へのセクションの割り当て(P. 5-37) 空き領域の予約(P. 5-37) ARM ライブラリの配置(P. 5-39) プリプロセッシングディレクティブの使用(P. 5-41) スキャッタローディングの記述におけるベニア入力セクションの選択 ベニアは、ARM コードと Thumb® コードの切り替えや、1 つの命令で指定できるジャ ンプよりも長いジャンプを実行する場合に使用します(「ベニアの生成」 (P. 3-21)参 照)。スキャッタローディング記述ファイルを使用することにより、リンカによって生 成されるベニア入力セクションを配置できます。スキャッタローディング記述ファイ ル内で *(Veneer$$Code) セクションセレクタを使用できる実行領域は 1 つだけです。 リンカにより、*(Veneer$$Code) セクションセレクタによって識別される領域にベニア 入力セクションを配置するのが安全だと判断された場合、その配置が実行されます。た だし、アドレス範囲の問題や、実行領域のサイズ制限などにより、ベニア入力セクショ ンをその領域に割り当てられない場合もあります。指定した領域にベニアを追加でき ない場合は、ベニアを生成した、再配置された入力セクションを含む実行領域にその ベニアが追加されます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-29 スキャッタローディング記述ファイルの使用 注 旧バージョンの ARM ツールで作成されたスキャッタローディング記述ファイル内の *(IWV$$Code) のインスタンスは、*(Veneer$$Code) に自動的に変換されます。ただし、 新しく作成するスキャッタローディング記述ファイルでは *(Veneer$$Code) を使用し て下さい。 5.3.2 ルート実行領域の作成 イメージの初期エントリポイントを指定する場合、または ENTRY ディレクティブを 1 つ しか使用していないためにリンカによって初期エントリポイントが作成される場合、 そのエントリポイントがルート領域内にあることを確認する必要があります。ルート 領域とは、ロードアドレスと実行アドレスが同一の領域です。初期エントリポイント がルート領域内にない場合はそのリンクは失敗し、リンカによって以下のようなエ ラーメッセージが生成されます。 Entry point (0x00000000) lies within non-root region ER_ROM スキャッタローディング記述ファイル内で、ある領域をルート領域として指定する場 合には、以下のいずれかの方法を使用できます。 • 実行領域の属性として、明示的にまたは標準の設定のままで ABSOLUTE を指定し、 最初の実行領域とそれを含むロード領域に同じアドレスを使用します。実行領域 のアドレスとロード領域に同じアドレスを指定するには、以下のいずれかの方法 を使用します。 — 実行領域とロード領域のベース指定子(アドレス)に同じ数値を指定する。 — ロード領域内の最初の実行領域のオフセットに +0 を指定する。 ロード領域内の 2 番目以降のすべての実行領域のオフセットにゼロ(+0) が指定されている場合には、それらの領域がすべてルート領域となります。 詳細については、例 5-2(5-31 ページ)を参照して下さい。 • FIXED 実行領域属性を使用して、特定の領域のロードアドレスと実行アドレスに 同じアドレスを指定します。詳細については、例 5-3(5-31 ページ)および P. 5-31 図 5-9 を参照して下さい。 FIXED 属性を使用して、ROM 内の特定のアドレスに任意の実行領域を配置できます。 詳細については、「領域を配置するアドレスの固定」 (P. 5-32)を参照して下さい。 5-30 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 例 5-2 ロードアドレスと実行アドレスに同じアドレスを指定する LR_1 0x040000 { ER_RO 0x040000 { * (+RO) ; load region starts at 0x40000 ; start of execution region descriptions ; load address = execution address ; all RO sections (must include section with ; initial entry point) } ; rest of scatter description... } 例 5-3 FIXED 属性の使用 LR_1 0x040000 { ER_RO 0x040000 { * (+RO) } ER_INIT 0x080000 FIXED ; load region starts at 0x40000 ; start of execution region descriptions ; load address = execution address ; RO sections other than those in init.o ; load address and execution address of this ; execution region are fixed at 0x80000 { init.o(+RO) ; all RO sections from init.o } ; rest of scatter description... } Filled with zeroes or the value defined using the --pad option init.o init.o Single load region 0x80000 (FIXED) Empty (moveable) *(RO) Load view *(RO) 0x4000 Execution view 図 5-9 固定実行領域のメモリマップ ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-31 スキャッタローディング記述ファイルの使用 5.3.3 領域を配置するアドレスの固定 実行領域のスキャッタローディング記述で FIXED 属性を使用して、ロードアドレスと実 行アドレスを固定したルート領域を作成できます。 FIXED 属性は、1 つのロード領域内に複数のルート領域を作成する場合に使用されます (したがって通常は 1 つの ROM デバイスに使用されます)。例えば、この属性を使用し て、関数または定数テーブルやチェックサムなどのデータブロックを ROM 内の固定ア ドレスに配置することで、ポインタを使用して容易にアクセスできます。 初期化コードを ROM の最初に配置し、チェックサムを ROM の最後に配置するような 場合には、メモリの一部が使用されない可能性があります。* または .ANY モジュール セレクタを使用することで、初期化ブロックの最後とデータブロックの最初の間にあ る領域を充填できます。 注 コードの保守とデバッグを容易にするには、スキャッタローディング記述ファイル内 での配置に関する指定を最小限に抑え、関数とデータの詳細な配置はリンカに委ねる ことをお勧めします。 部分的にリンクされたコンポーネントオブジェクトは指定できません。例えば、obj1.o、 obj2.o、obj3.o の 3 つのオブジェクトを部分的にリンクして obj_all.o を生成する場 合、結果として得られたオブジェクト内ではコンポーネントオブジェクトの名前は破 棄されます。したがって、いずれのオブジェクトも obj1.o などの名前で参照すること はできません。参照できるのは結合されたオブジェクト obj_all.o のみです。 特定アドレスへの関数とデータの配置 通常、コンパイラは 1 つのソースファイルから RO、RW、ZI の 3 つのセクションを生 成します。これらの領域には、ソースファイルのすべてのコードとデータが保持され ます。1 つの関数項目またはデータ項目を固定アドレスに配置するには、その関数また はデータを、入力ファイルの他の部分とは別にリンカに処理させる必要があります。 個々のオブジェクトにアクセスするには、以下のいずれかの方法を使用します。 • 関数またはデータ項目を、その関数やデータ項目しかない個別のソースファイル 内に配置する。 • --split_sections コンパイラオプションを使用して、各関数のオブジェクトファ イルを生成する(RealView Compilation Tools v3.0 Compiler and Libraries Guide 参照) 。 このオプションを指定すると、関数間でアドレス、データ、および文字列リテラ ルを共有する可能性が減るため、一部の関数でコードのサイズがわずかに(数 パーセント程度)増加します。しかし、armlink --remove を指定することによっ て、リンカは使用されていない関数を削除できるため、最終イメージの合計サイ ズを小さくすることができます。 5-32 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 • C または C++ ソースコード内で #pragma arm section を使用し、命名された複数 のセクションを作成する(例 5-5(5-34 ページ)参照)。 • アセンブリ言語から AREA ディレクティブを使用する。アセンブリコードで配置可 能な最小単位は AREA です(RealView Compilation Tools v3.0 Assembler Guide 参照)。 各オブジェクトファイルの内容の配置 例 5-4 に示すスキャッタローディング記述ファイルによって、以下の処理が行われま す。 • 初期化コードがアドレス 0x0 に配置されます(この後に、RO コードの残りと、オ ブジェクト data.o 内の RO データを除くすべての RO データが配置されます)。 • すべてのグローバル RW 変数が RAM 内の 0x400000 に配置されます。 • data.o 内の RO-DATA のテーブルがアドレス 0x1FF00 に固定されます。 例 5-4 セクションの配置 LOADREG1 0x0 0x10000 { EXECREG1 0x0 0x2000 { init.o (Init, +FIRST) * (+RO) } RAM 0x400000 { * (+RW +ZI) } DATABLOCK 0x1FF00 FIXED 0xFF { data.o(+RO-DATA) } } ARM DUI 0206GJ ; Root Region, containing init code ; place init code at exactly 0x0 ; rest of code and read-only data ; RW & ZI data to be placed at 0x400000 ; execution region fixed at 0x1FF00 ; maximum space available for table is 0xFF ; place RO data between 0x1FF00 and 0x1FFFF Copyright © 2002-2006 ARM Limited. All rights reserved. 5-33 スキャッタローディング記述ファイルの使用 注 FIXED 属性と 1 つのロード領域を使用することが適切ではない場合があります。固定位 置の指定に関しては以下のような方法もあります。 • ローダで複数のロード領域を処理できる場合には、RO コードまたはデータを専 用のロード領域内に配置します。 • 関数またはデータを ROM 内の固定位置に配置する必要がない場合には、FIXED 属 性の代わりに ABSOLUTE 属性を使用します。この属性を使用すると、ローダはロー ド領域から RAM 内の指定されたアドレスにデータをコピーします(ABSOLUTE が 標準の設定の属性です)。 • メモリマップされた I/O の位置にデータ構造を配置するには、2 つのロード領 域を使用して UNINIT 属性を指定します(UNINIT 属性を指定すると、そのメモ リ位置はゼロで初期化されません)。詳細については、RealView Compilation Tools v3.0 Developer Guide の組み込みソフトウェアの開発方法に関する章を参照して 下さい。 arm セクションプラグマの使用 コードまたはデータのオブジェクトを専用のソースファイル内に配置した後、そのオ ブジェクトファイルのセクションを配置するには、標準的なコーディング方法を使用 します。しかし、プラグマやスキャッタローディング記述ファイルを使用して、命名 されたセクションを配置することもできます。例 5-5 で示すように、モジュール (adder.c など)を作成し、セクションを明示的に命名します。 例 5-5 セクションの命名 // file int int int int adder.c x1 = 5; y1[100]; const z1[3] = {1,2,3}; sub1(int x) {return x-1;} // // // // #pragma arm section rwdata = "foo", int x2 = 5; // char *s3 = "abc"; // int add1(int x) {return x+1;} // #pragma arm section code, rwdata // 5-34 in in in in .data .bss .constdata .text code ="foo" in foo (data part of region) s3 in foo, "abc" in .constdata in foo (.text part of region) return to default placement Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 スキャッタローディング記述ファイルを使用して、命名されたセクションを配置する 位置を指定できます(例 5-6(5-35 ページ)参照)。コードセクションとデータセクショ ンに同一の名前が付けられている場合には、コードセクションが先に配置されます。 例 5-6 セクションの配置 FLASH 0x24000000 0x4000000 { FLASH 0x24000000 0x4000000 { init.o (Init, +First) * (+RO) } 32bitRAM 0x0000 { vectors.o (Vect, +First) * (+RW,+ZI) } ADDER 0x08000000 { adder.o (foo) } } ARM DUI 0206GJ ; place area Init from init.o first ; sub1(), z1[] ; x1, y1 ; x2, string s3, and add1() Copyright © 2002-2006 ARM Limited. All rights reserved. 5-35 スキャッタローディング記述ファイルの使用 5.3.4 オーバーレイを使用したセクションの配置 OVERLAY キーワードをスキャッタローディング記述ファイルで使用して、同一のアドレ スに複数の実行領域を配置できます。例 5-7 では、RAM にスタティックなセクション を定義して、その後に一連のオーバーレイを設定しています。ここでは、そのセクショ ンの 1 つだけを実行時にインスタンス化しています。 例 5-7 ルート領域の指定 EMB_APP 0x8000 { . . STATIC_RAM 0x0 { * (+RW,+ZI) } OVERLAY_A_RAM 0x1000 OVERLAY { module1.o (+RW,+ZI) } OVERLAY_B_RAM 0x1000 OVERLAY { module2.o (+RW,+ZI) } . . } ; contains most of the RW and ZI code/data ; start address of overlay... ; rest of scatter description... スタティックな領域の長さが不明な場合、ゼロ相対オフセットを使用してオーバーレ イの開始アドレスを指定することで、オーバーレイはスタティックなセクションの直 後に配置されます。以下に例を示します。 OVERLAY_A_RAM +0 OVERLAY この場合、+offset が同一の連続するオーバーレイ領域は、前のオーバーレイ領域でな い領域から、またはロード領域の開始位置から +offset バイト離れた位置に配置されま す。(スタティックな領域が小さい場合)RAM が使用されないのを回避するため、ま たは(スタティックな領域が大きい場合)スタティックな領域がオーバーレイで上書 きされないようにするため、このような配置を行います。 5-36 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 5.3.5 ルート領域へのセクションの割り当て RVCT v2.1 以前では、ルートに配置する必要があったライブラリセクションは、__main と領域テーブルのみでした。しかし、RW データ圧縮の実装により、他にもルート領域 に配置する必要があるセクションが出てきました。それらのセクションはいずれも、 InRoot$$Sections を指定することでリンカによって自動的にルートに配置されます。 スキャッタローディング記述ファイルを使用して、命名されたセクションと同様に ルートセクションを指定できます。例 5-8 では、セクションセレクタ InRoot$$Sections を使用して、ルート領域に配置する必要があるすべてのセクションを ER_ROOT 領域に配 置しています。 例 5-8 ルート領域の指定 LR_FLASH 0x0 { ER_ROOT 0x0 { vectors.o (Vectors, +FIRST) * (InRoot$$Sections) } . . ; root region at 0x0 ; vector table ; all library sections that must be ; in a root region ; rest of scatter description... } 5.3.6 空き領域の予約 実行領域のスキャッタローディング記述で EMPTY 属性を使用して、スタック用の空きメ モリブロックを予約できます。 このメモリブロックはロード領域の一部ではありませんが、実行時で使用するために 割り当てられます。このメモリブロックはダミーの ZI 領域として作成されるため、リ ンカがこのブロックにアクセスするときは以下のシンボルが使用されます。 • Image$$region_name$$ZI$$Base • Image$$region_name$$ZI$$Limit • Image$$region_name$$ZI$$Length 長さに負の値が指定されている場合は、指定されているアドレスが、その領域の終了 アドレスとして使用されます。このアドレスは、相対アドレスではなく絶対アドレス にして下さい。例えば、例 5-9(5-38 ページ)に示す実行領域の定義 STACK 0x800000 EMPTY -0x10000 では、アドレス 0x7F0000 で始まり、アドレス 0x800000 で終わる、STACK と呼ばれる領域が定義されています。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-37 スキャッタローディング記述ファイルの使用 注 EMPTY 実行領域のために作成されるダミーの ZI 領域は、実行時にゼロで初期化されま せん。 相対アドレス(+n)を指定し、負の長さを指定した場合、エラーが生成されます。 例 5-9 スタック用の領域の予約 LR_1 0x80000 { STACK 0x800000 EMPTY -0x10000 ; load region starts at 0x80000 ; region ends at 0x800000 because of the ; negative length. The start of the region ; is calculated using the length. { ; Empty region used to place stack } HEAP +0 EMPTY 0x10000 ; region starts at the end of previous ; region. End of region calculated using ; positive length { ; Empty region used to place heap } ; rest of scatter description... } 図 5-10 に、この例を図示します。 0x81000 Limit Heap 0x80000 Stack 0x7F000 Base Limit Base 図 5-10 スタック用の領域の予約 5-38 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 この例では、リンカによって以下のシンボルが生成されます。 Image$$STACK$$ZI$$Base Image$$STACK$$ZI$$Limit Image$$STACK$$ZI$$Length Image$$HEAP$$ZI$$Base Image$$HEAP$$ZI$$Limit Image$$HEAP$$ZI$$Length = = = = = = 0x7f0000 0x800000 0x1000 0x800000 0x810000 0x1000 注 EMPTY 属性は実行領域のみに適用されます。EMPTY 属性がロード領域の定義に使用され ている場合は、リンカによって警告が生成され、この属性は無視されます。 リンカは、EMPTY 領域に使用されるアドレス空間が、他の実行領域に使用されていない かどうかをチェックします。 5.3.7 ARM ライブラリの配置 ARM の C および C++ の標準ライブラリのコードをスキャッタローディング記述ファ イルに配置できます。以下に例を示します。 ER 0x2000 { *c_t__un.l (+RO) : } ただし、スキャッタローディング記述ファイルのライブラリ名の命名規則が今後のリ リースで変更された場合にもライブラリ名を解決できるようにするため、上記の方法 ではなく *armlib または *armlib* を使用することをお勧めします。以下に例を示し ます。 ER 0x2000 { *armlib* (+RO) ; all ARM-supplied C libraries : } ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-39 スキャッタローディング記述ファイルの使用 例 5-10(5-40 ページ)は、ライブラリコードの配置方法を示しています。 注 例 5-10(5-40 ページ)では、Windows、Sun Solaris、Red Hat Linux のいずれのプラット フォームでも認識されるよう、パス名にスラッシュを使用しています。 例 5-10 ARM ライブラリコードの配置 ROM1 0 { * (InRoot$$Sections) * (+RO) } ROM2 0x1000 { *armlib/h_* (+RO) ; ; } ROM3 0x2000 { *armlib/c_* (+RO) ; } RAM1 0x3000 { *armlib* (+RO) ; ; } RAM2 0x4000 { * (+RW, +ZI) } 5-40 just the ARM-supplied __ARM_* redistributable library functions all ARM-supplied C library functions all other ARM-supplied library code e.g. floating-point libs Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 5.3.8 プリプロセッシングディレクティブの使用 スキャッタローディング記述ファイルの最初の行で、ファイルを処理するために呼び 出すプリプロセッサを指定します。このコマンドの形式を以下に示します。 #! <preprocessor> [pre_processor_flags] 一般的には、#! armcc -E というコマンドが使用されます。 リンカは、使用されている演算子が +、-、*、/、AND、OR、および丸括弧のみの単純な 式を評価できます。OR および AND の実装は、C の演算子の優先順位に従います。 プリプロセッシングディレクティブは、スキャッタローディング記述ファイルの先頭 に追加します。以下に例を示します。 #define ADDRESS 0x20000000 #include "include_file_1.h" これらのディレクティブがコメントとして処理され無視された、前処理済みのス キャッタローディング記述ファイルがリンカによって解析されます。 以下の例を考えてみます。 #define AN_ADDRESS (BASE_ADDRESS+(ALIAS_NUMBER*ALIAS_SIZE)) 次のディレクティブを使用します。 #define BASE_ADDRESS 0x8000#define ALIAS_NUMBER 0x2#define ALIAS_SIZE 0x400 スキャッタローディング記述ファイルの内容を、次のように仮定します。 LOAD_FLASH AN_ADDRESS ; start address 前処理の後の評価は次のとおりです。 LOAD_FLASH ( 0x8000 + ( 0x2 * 0x400 )) ; start address 評価の後、スキャッタローディング記述ファイルが解析されて、ロード領域が作成さ れます。 LOAD_FLASH 0x8808 ; start address ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-41 スキャッタローディング記述ファイルの使用 5.4 等価なスキャッタローディング記述を使用した単純イメージの生成 コマンドラインオプション(--reloc、--ro-base、--rw-base、--ropi、--rwpi、--split) を指定すると、 「コマンドラインオプションを使用した単純イメージの作成」(P. 3-28) で説明されているタイプの単純イメージが作成されます。これと同じタイプのイメー ジは、--scatter コマンドラインオプションと、対応するスキャッタローディングの記 述の 1 つを含むファイルを使用して、作成することができます。 このセクションでは、以下の内容について説明します。 • タイプ 1:1 つのロード領域と連続する出力領域 • • 5.4.1 タイプ 2:1 つのロード領域と連続しない出力領域(P. 5-44) タイプ 3:2 つのロード領域と連続しない出力領域(P. 5-46) タイプ 1:1 つのロード領域と連続する出力領域 このタイプのイメージは、ロードビュー内の 1 つのロード領域と、実行ビュー内の 3 つ の実行領域から構成されます。実行領域はメモリマップ内で連続して配置されます。 --ro-base address によって、RO 出力セクションを含む領域のロードアドレスと実行 アドレスが指定されます。例 5-11 は、--ro-base 0x040000 を使用することと同じ意味 を持つスキャッタローディングの記述を示しています。 例 5-11 1 つのロード領域と連続する実行領域 LR_1 0x040000 { ER_RO +0 ; Define the load region name as LR_1, the region starts at 0x040000. ; First execution region is called ER_RO, region starts at end of previous region. ; However, since there was no previous region, the address is 0x040000. { * (+RO) } ER_RW +0 ; All RO sections go into this region, they are placed consecutively. ; Second execution region is called ER_RW, the region starts at the end of the ; previous region.The address is 0x040000 + size of ER_RO region. { * (+RW) } ER_ZI +0 ; All RW sections go into this region, they are placed consecutively. ; Last execution region is called ER_ZI, the region starts at the end of the ; previous region at 0x040000 + the size of the ER_RO regions + the size of ; the ER_RW regions. { * (+ZI) ; All ZI sections are placed consecutively here. } } 5-42 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 例 5-11(5-42 ページ)の記述によって、ロードアドレスに 0x040000 が設定された、LR_1 という名前の 1 つのロード領域を含むイメージが作成されます。 このイメージには、ER_RO、ER_RW、ER_ZI と命名された 3 つの実行領域があり、それぞ れ RO、RW、ZI の各出力セクションを含んでいます。RO と RW はルート領域です。 ZI は実行時に動的に作成されます。ER_RO の実行アドレスは 0x040000 です。実行領域 の記述において、+offset 形式のベース指定子を使用することにより、3 つの実行領域 がすべてメモリマップ内で連続して配置されます。これにより、実行領域をその前の 実行領域の直後に配置できます。 --reloc オプションを使用すると、再配置可能なイメージを作成できます。--reloc を 単独で使用すると、単一のロード領域の属性が RELOC に設定される、単純タイプ 1 に似 たイメージを生成します。 ropi の例 このバリアントでは、実行領域はメモリマップ内で連続して配置されます。しかし、 --ropi を指定すると、RO 出力セクションを保持するロード領域と実行領域が位置非依 存としてマークされます。 例 5-12 は、--ro-base 0x010000 --ropi を使用することと同じ意味を持つスキャッタ ローディングの記述を示しています。 例 5-12 位置に依存しないコード LR_1 0x010000 PI { ER_RO +0 ; The first load region is at 0x010000. ; The PI attribute is inherited from parent. ; The default execution address is 0x010000, but the code can be moved. { * } ER_RW { * } ER_ZI { * } (+RO) ; All the RO sections go here. +0 ABSOLUTE ; PI attribute is overridden by ABSOLUTE. (+RW) ; The RW sections are placed next. They cannot be moved. +0 ; ER_ZI region placed after ER_RW region. (+ZI) ; All the ZI sections are placed consecutively here. } ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-43 スキャッタローディング記述ファイルの使用 例 5-12(5-43 ページ)に示すとおり、RO 実行領域である ER_RO はロード領域 LR_1 の PI 属性を継承します。次の実行領域 ER_RW は ABSOLUTE としてマークされ、+offset 形 式のベース指定子が使用されます。このため、ER_RW には ER_RO の PI 属性が継承されま せん。また、ER_ZI 領域のオフセットに +0 が設定されているため、この領域は ER_RW 領 域の ABSOLUTE 属性を継承します。 5.4.2 タイプ 2:1 つのロード領域と連続しない出力領域 このタイプのイメージは、ロードビュー内の 1 つのロード領域と、実行ビュー内の 3 つ の実行領域から構成されます。RW 実行領域が RO 実行領域と隣接しないことを除いて は、タイプ 1 のイメージと似ています。 --ro-base address1 によって、RO 出力セクションを含む領域のロードアドレスと実行 アドレスが指定されます。--rw-base address2 によって、RW 実行領域の実行アドレス が指定されます。 例 5-13 は、--ro-base 0x010000 --rw-base 0x040000 を使用することと同じ意味を持つ スキャッタローディングの記述を示しています。 例 5-13 1 つのロード領域と複数の実行領域 LR_1 0x010000 { ER_RO +0 ; Defines the load region name as LR_1 ; The first execution region is called ER_RO and starts at end of previous region. ; Since there was no previous region, the address is 0x010000. { * } ER_RW { * } ER_ZI (+RO) ; All RO sections are placed consecutively into this region. 0x040000 ; Second execution region is called ER_RW and starts at 0x040000. (+RW) ; All RW sections are placed consecutively into this region. +0 ; The last execution region is called ER_ZI. ; The address is 0x040000 + size of ER_RW region. * (+ZI) ; All ZI sections are placed consecutively here. { } } 5-44 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 この記述により、ロードアドレスに 0x010000 が設定された、LR_1 という名前の 1 つの ロード領域を含むイメージが作成されます。 このイメージには、ER_RO、ER_RW、ER_ZI と命名された 3 つの実行領域があり、それぞ れ RO、RW、ZI の各出力セクションを含んでいます。RO 領域はルート領域です。ER_RO の実行アドレスは 0x010000 です。 ER_RW 実行領域と ER_RO 実行領域は隣接していません。この領域の実行アドレスは 0x040000 です。 ER_ZI 実行領域は、その前の実行領域である ER_RW の直後に配置されます。 rwpi の例 RW 実行領域と RO 実行領域が隣接していない点で、--rw-base を指定して作成するタ イプ 2 のイメージと似ています。ただし、--rwpi を指定すると、RW 出力セクションを 保持する実行領域が位置非依存としてマークされます。 例 5-14 は、--ro-base 0x010000 --rw-base 0x018000 --rwpi を使用することと同じ意味 を持つスキャッタローディングの記述を示しています。 例 5-14 位置に依存しないデータ LR_1 0x010000 { ER_RO +0 ; The first load region is at 0x010000. ; Default ABSOLUTE attribute is inherited from parent. The execution address ; is 0x010000. The code and ro data cannot be moved. { * } ER_RW { * } ER_ZI { * } (+RO) ; All the RO sections go here. 0x018000 PI ; PI attribute overrides ABSOLUTE (+RW) ; The RW sections are placed at 0x018000 and they can be moved. +0 ; ER_ZI region placed after ER_RW region. (+ZI) ; All the ZI sections are placed consecutively here. } RO 実行領域である ER_RO はロード領域 LR_1 の ABSOLUTE 属性を継承します。次の実行 領域である ER_RW は、PI としてマークされます。また、ER_ZI 領域のオフセットに +0 が 設定されているため、この領域は ER_RW 領域の PI 属性を継承します。 タイプ 2 とタイプ 3 のイメージに、--ropi と --rwpi の他の組み合わせを使用するス キャッタローディングの記述も可能です。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 5-45 スキャッタローディング記述ファイルの使用 5.4.3 タイプ 3:2 つのロード領域と連続しない出力領域 タイプ 3 のイメージは、ロードビュー内の 2 つのロード領域と、実行ビュー内の 3 つ の実行領域から構成されます。このタイプのイメージはタイプ 2 のイメージと似てい ますが、このイメージではタイプ 2 の 1 つのロード領域が 2 つのロード領域に分割さ れます。 ロード領域の再配置と分割を行うには、以下のリンカオプションを使用します。 --reloc --reloc --split の組み合わせを使用すると、単純タイプ 3 に似たイメー ジが生成されますが、2 つのロード領域には RELOC 属性が設定されます。 --ro-base address1 RO 出力セクションを含む領域のロードアドレスと実行アドレスを指定 します。 --rw-base address2 RW 出力セクションを含む領域のロードアドレスと実行アドレスを指定 します。 --split RO 出力セクションと RW 出力セクションを含む標準の設定の 1 つの ロード領域を 2 つのロード領域に分割する場合に使用します。これによ り、一方のロード領域には RO 出力セクションが、他方には RW 出力セ クションが含まれます。 例 5-15(5-47 ページ)は、--ro-base 0x010000 --rw-base 0x040000 --split を使用する ことと同じ意味を持つスキャッタローディングの記述を示しています。 この例では、以下のようになります。 • 0x010000 と 0x040000 をロードアドレスとする 2 つのロード領域 LR_1 および LR_2 を含むイメージが作成されます。 5-46 • このイメージには、ER_RO、ER_RW、ER_ZI と命名された 3 つの実行領域があり、そ れぞれ RO、RW、ZI の各出力セクションを含んでいます。ER_RO の実行アドレス は 0x010000 です。 • ER_RW 実行領域と ER_RO 実行領域は隣接していません。この領域の実行アドレス は 0x040000 です。 • ER_ZI 実行領域は、その前の実行領域である ER_RW の直後に配置されます。 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ スキャッタローディング記述ファイルの使用 例 5-15 複数のロード領域 LR_1 0x010000 { ER_RO +0 { * (+RO) } } LR_2 0x040000 { ER_RW +0 { * (+RW) } ER_ZI +0 { * (+ZI) } } ARM DUI 0206GJ ; The first load region is at 0x010000. ; The address is 0x010000. ; The second load region is at 0x040000. ; The address is 0x040000. ; All RW sections are placed consecutively into this region. ; The address is 0x040000 + size of ER_RW region. ; All ZI sections are placed consecutively into this region. Copyright © 2002-2006 ARM Limited. All rights reserved. 5-47 スキャッタローディング記述ファイルの使用 再配置可能なロード領域の例 このタイプ 3 のイメージも、ロードビュー内の 2 つのロード領域と、実行ビュー内の 3 つの実行領域から構成されます。しかし、ここでは 2 つのロード領域に RELOC 属性を 設定するために、--reloc を使用します。 例 5-16 は、--ro-base 0x010000 --rw-base 0x040000 --reloc --split を使用することと 同じ意味を持つスキャッタローディングの記述を示しています。 例 5-16 再配置可能なロード領域 LR_1 0x010000 RELOC { ER_RO + 0 { * (+RO) } } LR2 0x040000 RELOC { ER_RW + 0 { * (+RW) } ER_ZI +0 { * (+ZI) } } 5-48 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 第6章 System V の共有ライブラリ 本章では、ARM® リンカ armlink における System V の共有ライブラリのサポートつい て説明します。本章は以下のセクションから構成されています。 • System V の共有ライブラリについて(P. 6-2) • ARM DUI 0206GJ SVr4 の共有ライブラリの使用(P. 6-3) Copyright © 2002-2006 ARM Limited. All rights reserved. 6-1 System V の共有ライブラリ 6.1 System V の共有ライブラリについて Base Platform ABI for the ARM Architecture[BPABI]では、静的なリンカによって生成さ れた実行可能ファイルや共有オブジェクトファイルの形式と内容を規定しています。 BPABI は、ポストリンクを使用してプラットフォーム固有の実行可能ファイルをサポー トすると共に、プラットフォーム ABI を得るための base standard にもなります。この base standard には、共有オブジェクトモデルに基づき、以下の 3 つのプラットフォーム ファミリが定義されています。 • ベアメタル • DLL • System V リリース 4 (SVr4) リンカは BPABI に準拠しているので、以下のことが可能です。 • オブジェクトとライブラリのコレクションを次のものにリンクする。 — ベアメタル実行可能イメージ — BPABI DLL または SVr4 の共有オブジェクト — BPABI または SVr4 の実行可能ファイル • オブジェクトのコレクションを共有ライブラリにリンクする。 • オブジェクトのコレクションを 1 つのオブジェクトに部分的にリンクし、そのオ ブジェクトを次のリンク手順の入力として使用する。 本章の残りの部分で、SVr4 の共有ライブラリのサポートについて説明します。 BPABI DLL の詳細については、Base Platform ABI for the ARM Architecture [BPABI]を 参照して下さい。 6.1.1 追加の詳細情報 base standard、ソフトウェアインタフェース、および ARM でサポートされている標準 に関する詳細については、install_directory\Documentation\Specifications\... を参 照して下さい。 最新版の詳細については、http://www.arm.com を参照して下さい。 ARM Application Note 150 Building Linux Applications Using RVCT and the GNU Tool and Libraries も参照して下さい。 汎用 System V ABI (ドラフト)の詳細については、http://www.sco.com を参照して下 さい。 6-2 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ System V の共有ライブラリ 6.2 SVr4 の共有ライブラリの使用 リンカを使用して、SVr4 の共有ライブラリを構築し、共有ライブラリにオブジェクト をリンクできます。 このセクションでは、以下の内容について説明します。 • ARM Linux 実行可能ファイルの作成 • • • • 6.2.1 シンボルへのアクセス(P. 6-5) 例外テーブル(P. 6-7) スレッドローカル記憶域(P. 6-7) 動的リンカの使用(P. 6-8) ARM Linux 実行可能ファイルの作成 --sysv コマンドラインオプションを使用して、ARM Linux で使用できる SVr4 形式の ELF 実行可能ファイルを生成します。 注 --sysv を使用すると、コマンドラインで指定したスキャッタローディング記述ファイ ルは無視されます。 実行可能ファイルの標準の設定のベースアドレスは 0x8000 です。コマンドラインで共 有オブジェクトが指定されている場合、参照の解決と動的な実行可能ファイルの作成 にそれらのオブジェクトが使用されます。 コマンドラインで共有オブジェクトが指定されていることが検出された場合、実行可 能ファイルに追加するライブラリのリストにそのオブジェクトが追加されます(詳細 については、「ライブラリの検索、選択、スキャン」(P. 7-3)を参照して下さい)。 ARM Linux を使用している場合は、以下の点に注意して下さい。 ARM DUI 0206GJ • 実行可能ファイルのコピーとゼロによる初期化は、すべて Linux カーネルにより 実行されます。 • RW データは圧縮されません。 • 実行可能ファイルは、常に ARM 状態で開始されます。 Copyright © 2002-2006 ARM Limited. All rights reserved. 6-3 System V の共有ライブラリ 共有オブジェクトの作成 共有オブジェクトには、 「ARM Linux 実行可能ファイルの作成」(P. 6-3)で説明した静 的リンクおよび動的リンクの拡張機能があります。ロード領域のベースアドレスは 0 に 設定された後、Linux 動的リンカによって再配置されます。 エクスポートする RW データが共有オブジェクトに含まれている場合、位置に依存し ないコードおよびデータを使用する必要があります。この場合、--apcs /fpic を使用し てファイルをコンパイルまたはアセンブルし、--fpic リンカオプションを使用して共 有オブジェクトにファイルをリンクする必要があります。 SVr4 共有オブジェクトを作成するには、--shared コマンドラインオプションを使用し ます。 注 通常、共有オブジェクトには、エントリポイントがありませんが、エントリポイント を設定することは可能です。動的リンカを作成している場合、エントリポイントを設 定する必要があります。 Linux ABI タグの使用 Linux Standard Base Specification v1.2 に準拠するには、SHT_NOTE タイプの .note.ABI-tag というセクションを ELF 仕様の記載に従って注釈セクションとして構成し、このセク ションを実行可能ファイルに含める必要があります。 コマンドラインオプション --linux_abitag を使用して、作成している実行可能ファイ ルと最小限の 互換性を持つカーネルバージョンを指定できます。以下に例を示します。 armlink ... --sysv --linux_abitag 2.2.5 main.o このコマンドは、Linux カーネル v2.2.5 以降と互換性を持つように定義された静的実行 可能ファイルに main.o をリンクします。これより新しい カーネルを必要とする共有オ ブジェクトをコマンドラインで指定した場合、出力ファイルのカーネル要件がそれに 合わせて引き上げられます。 Linux ABI タグの使用と Linux Standard Base Specification の詳細については、 http://www.linuxbase.org を参照して下さい。 6-4 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ System V の共有ライブラリ 6.2.2 シンボルへのアクセス シンボルテーブルを使用すると、リンクステージに含まれる非共有のオブジェクトが 参照している共有オブジェクト内のシンボルを判断できます。参照されているシンボ ルがある場合、共有オブジェクトからインポートされたものとして定義されます。 リンカはシンボルバージョンをサポートしています。シンボルバージョンは、シンボ ルテーブルに有用な情報を提供します。 • バージョン管理された共有オブジェクトのローカル有効範囲が設定されたシン ボルは、外部から参照されません。 • グローバル有効範囲が設定されたバージョン管理シンボルにはバージョンがな いので、通常のシンボル照合が適用されます。 • HIDDEN 可視化属性を設定したバージョン管理シンボルは、現在使用が制限されて います。静的リンカはこの設定を無視します。 • 標準の設定のシンボルは、HIDDEN 可視化属性が設定されていないバージョン管理 シンボルです。 シンボルのバージョン管理テーブルを含む共有オブジェクトをロードした場合(さら に、バージョン管理シンボルへの参照が一致した場合) 、シンボルのバージョン管理情 報がシンボルテーブルに追加されます。バージョンスクリプトファイルを使用して、エ クスポートするシンボルのリストを指定できます。以下に例を示します。 armlink file_1.o file_2.o --sysv --shared -o libfoo.so --symver_script ver_script.txt シンボルの解決 リンカは、オブジェクトが共有か非共有かにかかわらず、同じ方法でシンボルを解決 します。未定義の参照が共有オブジェクト内の定義と一致した場合、その参照を動的 シンボルテーブルに配置してインポートします。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 6-5 System V の共有ライブラリ シンボルのインポートとエクスポート ステアリングファイルを使用している場合、EXPORT を使用して、エクスポートするシ ンボルを指定します。 未定義のシンボル参照は、コマンドラインで指定した共有オブジェクトの動的シンボ ルテーブルに一致する定義があった場合にインポートされます。インポートされたシ ンボルは、後でエクスポートするシンボルと見なされます。 共有オブジェクトを作成するときは、ステアリングファイルのコマンドの影響を受け るシンボル、またはソースファイルで __declspec(dllexport) を使用してエクスポート されるシンボルのみがエクスポートされます。ステアリングファイルのコマンドを指 定しない場合、グローバルな(非表示でない)すべてのシンボルが通常エクスポート されます。 非表示でないシンボルとは、アセンブラソースで可視化属性 DYNAMIC または PROTECTED が 指 定 さ れ て い る か、あ る い は C ソースコードに __declspec(dllimport) または __declspec(dllexport) が含まれているシンボルです。 実行可能ファイルを作成するときは、イメージを Linux プラットフォームで正しく実行 するために必要なシンボルのみがエクスポートされます。つまり、共有オブジェクト で検出されたシンボルがインポートされます。それ以外に動的シンボルテーブルに挿 入するシンボルを定義するには、ステアリングファイルのコマンドを使用します。 注 未定義の参照が残っている場合、armlink によりエラーが生成されます。 EXPORT の使用方法の詳細については、 「ステアリングファイルのコマンド」 (P. 4-13)を 参照して下さい。 6-6 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ System V の共有ライブラリ 6.2.3 例外テーブル 共有ライブラリを使用しない静的イメージがリンカによって例外をスローできないと 判断された場合、そのイメージの例外テーブルは自動的に破棄されます。 共有オブジェクトを使用するイメージをリンクするときは、すべての共有オブジェク --force_so_throw コマンドラインオプション トが例外をスローする可能性があるので、 を使用して、イメージが例外をスローできるかどうかとは無関係に、例外テーブルを 保持するようリンカに指示します。 PT_ARM_EXIDX プログラムヘッダの追加 SVr4 形式の ELF 実行可能ファイルを作成している場合、--pt_arm_exidx コマンドライ ンオプションを使用して、例外テーブルと動的な内容を含むイメージまたは共有オブ ジェクトに PT_ARM_EXIDX タイプのプログラムヘッダを追加します。このヘッダには、 イメージの unwind テーブルの場所を記載します。また、例外テーブルのファイルオフ セット、仮想アドレス、およびサイズをプログラムローダに通知するフィールドも含 めます。 リンカでは、共有オブジェクトに PT_ARM_EXIDX プログラムヘッダが含まれていると、 例外がスローされる可能性があると判断します。したがって、例外をスローできるか どうかに関係なく、共有オブジェクトは例外テーブルを保持する必要があります。 標準の設定は --no_pt_arm_exidx です。 6.2.4 スレッドローカル記憶域 最新リリースのリンカでは、SVr4 のイメージおよび共有ライブラリのスレッドローカ ル記憶域(TLS)のみがサポートされます。リンカの実装の詳細については、ABI for the ARM Architecture [ABI-addenda]の正誤表および追捕表を参照して下さい。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 6-7 System V の共有ライブラリ 6.2.5 動的リンカの使用 共有オブジェクトまたは実行可能ファイルには、動的リンカがファイルを正しくロー ドして実行するために必要なすべての情報が含まれます。 • オブジェクトを識別する SONAME がすべての共有オブジェクトに含まれています。 この名前は、コマンドラインで --soname name オプションを使用することで指定 できます。 • 他の共有オブジェクトとの依存関係を特定するため、コマンドラインで指定され た共有オブジェクトが使用されます。共有オブジェクトの依存関係は、DT_NEEDED タグにエンコードされます。最新リリースでは、コマンドラインで指定されてい るライブラリの順序にこれらのタグの順序を合わせます。 • --sysv --shared を使用して共有ライブラリを作成する場合、ARM C ライブラリ の初期化関数 __cpp_initialize__aeabi_ は標準の設定ではインクルードされま せん。その代わりに、動的リンカがライブラリを初期化するために、必要であれ ば DT_INIT_ARRAY タグが設定されます。 共有ライブラリの初期化に __cpp_initialize__aeabi_ 関数を使用する場合、コマ ンドラインに --ref_cpp_init を追加し、--init=__cpp_initialize_aeabi_ を設定 する必要があります。 • --fini symbol コマンドラインオプションを指定した場合、指定されたシンボル 名で終了処理コードが定義されます。実行可能ファイルまたは共有オブジェクト をアンロードするときに、動的リンカによってこのコードが実行されます。 _fini というシンボルがこのコードにマークを付けるという前提はありません。 • --fini symbol コマンドラインオプションを指定した場合、指定されたシンボル 名で終了処理コードが定義されます。実行可能ファイルまたは共有オブジェクト をアンロードするときに、動的リンカによってこのコードが実行されます。 _fini というシンボルがこのコードにマークを付けるという前提はありません。 実 行 時 の フ ァ イ ル の ロ ー ド と 再 配 置 に 使 用 す る 動 的 リ ン カ を 指 定 す る に は、 Linux プラットフォー --dynamiclinker name コマンドラインオプションを使用します。 ムで作業している場合は、/lib/ld-linux.so.2 が標準の設定の動的リンカと見なされ ます。 6-8 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 第7章 ライブラリの作成と使用 本章では、ARM® リンカ armlink でのライブラリの使用方法とライブラリアン armar に ついて説明します。本章は以下のセクションから構成されています。 • ライブラリについて(P. 7-2) ARM DUI 0206GJ • ライブラリの検索、選択、スキャン(P. 7-3) • ARM ライブラリアン(P. 7-7) Copyright © 2002-2006 ARM Limited. All rights reserved. 7-1 ライブラリの作成と使用 7.1 ライブラリについて オブジェクトファイルは、関数や変数などの外部シンボルを参照できます。リンカは、 これらの参照を、他のオブジェクトファイルやライブラリにある定義とのマッチング を行うことによって解決します。リンカは、ar 形式のファイルとして格納された ELF ファイル群をライブラリとして認識します。 --sysv を使用して SVr4 形式の ELF 実行可能ファイルを生成すると、リンカは共有オ ブジェクトをライブラリとして処理します。同様に、BPABI 互換の実行可能ファイル を生成すると、共有オブジェクトや DLL はライブラリとして処理されます。ただし、 共有オブジェクトや DLL は、以下の点でアーカイブとは異なります。 • シンボルが共有オブジェクトまたは DLL からインポートされる • シンボルのコードまたはデータがアーカイブからリンクしているファイルに抽 出される 本章の残りの部分では、アーカイブについて説明します。 7-2 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ ライブラリの作成と使用 7.2 ライブラリの検索、選択、スキャン リンカがオブジェクトファイルをイメージに追加する方法と、ライブラリをイメージ に追加する方法には、以下の違いがあります。 • 入力リスト内の各オブジェクトファイルは、それを参照するものがあるかどうか に関係なく、無条件に出力イメージに追加されます。ただし、少なくとも 1 つの オブジェクトが指定されている必要があります。 • ライブラリのメンバは、オブジェクトファイルまたは既にインクルードされてい るライブラリメンバからそのメンバへの非 weak 型の参照がある場合、またはリ ンカが明示的にそのメンバを追加するよう指示されている場合にのみ、出力にイ ンクルードされます。 注 ライブラリのメンバは、入力ファイルリスト内で明示的に要求されると、そのメ ンバによって現在の参照が解決されない場合でもロードされます。この場合、明 示的に要求されたメンバは、通常のオブジェクトと同様に処理されます。 未使用セクションは、--no_remove が使用されない限り、後で削除されます。 weak 型シンボルへの未解決の参照がある場合、ライブラリのメンバはロードされま せん。 注 --no_scanlib コマンドラインオプションを指定した場合、リンカは標準の設定の ARM ライブラリの検索を行わず、入力ファイルリストに指定されているライブラリのみを 使用して参照を解決します。 リンカは、ライブラリのリストを以下の方法で作成します。 1. 入力ファイルリスト内に明示的に指定されているすべてのライブラリをリスト に追加します。 2. 入力オブジェクト内に指定されている要求を満たすために、ユーザ指定の検索パ スを検証し、ARM 標準ライブラリを識別します。 検証したディレクトリおよびそのサブディレクトリから、最も適切なライブラリ のバリアントが選択されます。ARM が提供するライブラリには、そのメンバの 属性に基づいて命名されている複数のバリアントがあります。 このセクションでは、以下の内容について説明します。 • ARM ライブラリの検索(P. 7-4) • • ARM DUI 0206GJ ユーザライブラリの検索(P. 7-5) ライブラリのスキャン(P. 7-6) Copyright © 2002-2006 ARM Limited. All rights reserved. 7-3 ライブラリの作成と使用 7.2.1 ARM ライブラリの検索 ARM 標準ライブラリ用の検索パスは、以下の方法で指定できます。 • 環境変数 RVCT30LIB を使用します。これが標準の設定です。 • armlink コマンドラインに --libpath オプションを、コンマで区切ったペアレン トディレクトリのリストと共に追加します。 このリストは、ARM のライブラリディレクトリ armlib および cpplib のペアレ ントディレクトリで終わる必要があります。RVCT30LIB 環境変数はこのパスを保 持します。 注 リンカのコマンドラインオプション --libpath は、RVCT30LIB 変数によって指定 されたパスをオーバーライドします。 リンカは、--libpath または RVCT30LIB 変数によって指定されたそれぞれのペアレント ディレクトリを、入力オブジェクトからの各サブディレクトリ要求と組み合わせて、 ARM ライブラリを検索する場所を識別します。ペアレントディレクトリ内の ARM サ ブディレクトリの名前は、Lib$$Request$$sub_dir_name 形式のシンボルを使用して、コ ンパイル済みの各オブジェクト内に配置されます。 複数のライブラリで同じシンボルが定義されている場合、検索のシーケンスの性質に より、リスト内で最初に出てくるライブラリがリンカによって選択されます。 ARM ライブラリのバリアントの選択 ARM ライブラリには、それらのメンバオブジェクトの属性に基づくさまざまなバリア ントがあります。ARM ライブラリのバリアントは、そのライブラリの名前にコーディ ングされます。リンカは、ライブラリの検索時に識別された各ディレクトリから、最 も適切なバリアントを選択する必要があります。 リンカは、各入力オブジェクトの属性を蓄積し、それらの属性に最も適したライブラ リのバリアントを選択します。選択された複数のライブラリが同様に適している場合 には、最初に選択されたライブラリが採用され、残りのライブラリは採用されません。 最終的なリストには、参照を解決するためにリンカがスキャンするすべてのライブラ リが保持されます。 ライブラリのバリアントの詳細については、RealView Compilation Tools v3.0 Compiler and Libraries Guide の C および C++ ライブラリに関する章を参照して下さい。 7-4 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ ライブラリの作成と使用 7.2.2 ユーザライブラリの検索 ユーザライブラリは、以下の方法で指定できます。 • 入力ファイルリスト内にユーザライブラリを明示的にインクルードします。 • armlink コマンドラインに --userlibpath オプションを、コンマで区切ったディ レクトリのリストと共に追加し、ライブラリの名前を入力ファイルとして追加し ます。 コマンドラインでライブラリに完全パス名を指定しない場合、リンカは、--userlibpath オプションで指定されたディレクトリ内でライブラリを検索します。例えば、ディレ /mylib/my_lib.a を入力 クトリ /mylib に my_lib.a および other_lib.a が含まれる場合、 ファイルリストに追加するには、以下のコマンドを使用します。 armlink --userlibpath /mylib my_lib.a *.o ライブラリから特定のメンバを追加する場合、このコマンドでは、リンカで使用され る検索可能なライブラリのリストにライブラリが追加されません。特定のメンバを ロードし、検索可能なライブラリのリストにライブラリを追加するには、ライブラリ filename を単独でインクルードするだけでなく、library(member) も指定します。例え ば、strcmp.o をロードして、検索可能なライブラリのリストに mystring.lib を配置す るには、入力ファイルリストに以下の行を追加します。 mystring.lib(strcmp.o) mystring.lib 注 RVCT30LIB 環境変数またはリンカのコマンドラインオプション --libpath によって指定 される、ARM 標準ライブラリに使用される検索パスでは、ユーザライブラリは検索さ れません(「ARM ライブラリの検索」 (P. 7-4)参照)。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 7-5 ライブラリの作成と使用 7.2.3 ライブラリのスキャン リンカは、ライブラリのリストを構成すると、参照を解決するためにリスト内の各ラ イブラリを繰り返しスキャンします。 すべてのディレクトリが検索され、最も互換性のあるライブラリのバリアントが選択 されてライブラリのリストに追加されると、各ライブラリをスキャンして、必要なメ ンバをロードします。 1. その時点で解決されていない非 weak 型の参照について、リンカはリスト内のラ イブラリを順に検索して、一致する定義を探します。検出された最初の定義が手 順 2 のためにマークされます。 2. 3. 複数のライブラリで同じシンボルが定義されている場合、検索のシーケンスの性 質により、リスト内で最初に出てくるライブラリがリンカによって選択されま す。このため、入力ファイルリストにライブラリを追加することにより、ARM C ライブラリなどの他のライブラリの関数定義をオーバーライドできます。 手順 1 でマークされたライブラリのメンバがロードされます。メンバをロードす ると、weak 型の参照を含む、未解決の参照が解決される可能性があります。ま た、ライブラリのロードによって、新たに未解決の weak 型および非 weak 型の参 照が生じる可能性もあります。 手順 1 および手順 2 の処理は、非 weak 型のすべての参照が解決されるか、どの ライブラリでも解決できないことが判明するまで続けられます。 スキャン処理が完了しても非 weak 型の参照が解決されない場合は、リンカによってエ ラーメッセージが生成されます。 7-6 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ ライブラリの作成と使用 7.3 ARM ライブラリアン ARM ライブラリアン armar を使用すると、ELF オブジェクトファイル群またはライブ ラリ群をライブラリにまとめて保管できます。リンカには、複数のオブジェクトファ イルの代わりにこのようなライブラリを渡すことができます。ただし、オブジェクト ライブラリファイルとリンクした場合は、オブジェクトライブラリファイル内に保管 されているすべてのオブジェクトファイルとリンクした場合と同じ結果が得られると は限りません。これは、リンカが入力リストとライブラリを、以下のような異なる方 法で処理するためです。 • 入力リスト内の各オブジェクトは無条件で出力に表示されますが、armlink --remove オプションが指定されている場合、未使用の領域が削除されます。 • ライブラリファイルのメンバは、オブジェクトファイルまたは以前に処理された ライブラリファイルによって参照されている場合にのみ、出力にインクルードさ れます。 リンカによる入力ファイルの処理方法の詳細については、 「第 2 章 リンカのコマンド構 文」を参照して下さい。 このセクションでは、以下の内容について説明します。 • ライブラリアンのコマンドラインオプション • コマンドラインオプションの順序(P. 7-11) • 7.3.1 armar の使用例(P. 7-12) ライブラリアンのコマンドラインオプション ライブラリ内のファイルの追加または修正に使用する armar コマンドの構文は以下の とおりです。 armar [--help] [--create] [--diag_style arm|ide|gnu] [-c] [-d] [-m] [-q] [-r] [-u] [--vsn] [-v] [--via option_file] [ {-a|-b|-i} pos_name] library [file_list] ファイル情報またはライブラリ情報の抽出に使用する armar コマンドの構文は以下の とおりです。 armar [--help] [--diag_style arm|ide|gnu] [-C] [--entries] [-p] [-t] [-s] [--sizes] [-T] [--vsn] [-v] [--via option_file] [-x] [--zs] [--zt] library [file_list] ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 7-7 ライブラリの作成と使用 各パラメータには以下の意味があります。 -a library 内の新しいファイルをファイル pos_name の後に配置します。 同じコマンドラインで -b (または -i)を指定した場合、このオプショ ンは無効になります。 -b library 内の新しいファイルをファイル pos_name の前に配置します。 同じコマンドラインで -a を指定した場合、このオプションが優先され ます。 -i library 内の新しいファイルをメンバ pos_name の前に配置します(-b と 同じです) 。 同じコマンドラインで -a を指定した場合、このオプションが優先され ます。 pos_name 相対位置の決定に使用される既存のライブラリメンバの名前を指定しま す。この名前は、オプション -a、-b、および -i を使用して指定する必要 があります。 -C 情報の抽出が行われる際に、既存のファイルが同じような名前のファイ ルに置き換えないようライブラリアンに指示します。このオプションは、 -T と組み合わせることによって、短縮されたファイル名が同じ接頭文字 の付いたファイルに置き換えられるのを防ぐ場合にも便利です。 -c 通常はライブラリ作成時に標準エラーに書き込まれる診断メッセージを 抑止します。 --create library が既に存在する場合でも、新しいライブラリを作成します。 -d library から 1 つ以上のファイルを削除します。 --diag_style arm|ide|gnu 警告メッセージやエラーメッセージの形式を変更します。--diag_style arm が標準の設定です。--diag_style gnu を指定すると、gcc から返され る形式になり、--diag_style ide を指定すると Microsoft Visual Studio か ら返される形式になります。 --entries library 内で定義されているすべてのエントリポイントの一覧を出力し ます。一覧の形式は以下のとおりです。 ENTRY at offset num in section name of member 7-8 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ ライブラリの作成と使用 file_list 処理するファイルのリストを指定します。各ファイルは、完全パス名で 正確に指定します。パスには、絶対パス、ドライブおよびルートへの相 対パス、カレントディレクトリへの相対パスのいずれかを設定できます。 ライブラリ内のファイルの名前と比較する場合には、パスの終わりにあ るファイル名のみが使用されます。複数のパスオペランドが同じファイ ル名で終わる場合の結果は定義されていません。ファイルの指定には、 ワイルドカード * および ? を使用できます。 いずれかのファイルがライブラリである場合、armar はその入力ライブラ リのすべてのメンバをデスティネーションのライブラリにコピーしま す。コマンドライン上での項目の順序はそのまま保持されます。したがっ て、ライブラリファイルを指定することは、ライブラリに格納されてい る順序でそのライブラリのすべてのメンバを指定することと論理的には 同じです。 --help armar コマンドのオンライン情報を表示します。 library ライブラリファイルのパス名を指定します。 -m ファイルを移動します。pos_name と -a、-b、-i のいずれか指定されてい る場合、ファイルは新しい位置に移動されます。それ以外の場合は、ファ イルはライブラリの最後に移動されます。 -n シンボルテーブルの保存を抑止します。ライブラリがオブジェクトライ ブラリでない場合に使用します。 -p library 内のファイルの内容を stdout に出力します。 -q このオプションは -r のエイリアスです。 -r library 内のファイルを置き換えるか、またはファイルを追加します。 library が存在しない場合は、新しいライブラリファイルが作成され、診 断メッセージが標準エラーに書き込まれます。 file_list が指定されていないのにそのライブラリが存在する場合の結 果は定義されていません。既存のファイルに置き換わるファイルによっ て、ライブラリの順序が変更されることはありません。 -u オプションが指定されている場合は、更新日がライブラリファイルよ りも新しいファイルのみが置き換えられます。 -a、-b、-i のいずれかのオプションが使用されている場合には、pos_name を使用して、新しいファイルを pos_name の後に配置するか(-a)前に配 置するか(-b または -i)を指定する必要があります。指定されていない 場合、新しいファイルは最後に配置されます。 -t library の内容を表すテーブルを出力します。書き込まれるリストには、 file_list で指定されたファイルが含まれます。file_list が指定されて いない場合は、ライブラリ内のすべてのファイルが、保存された順序で 含まれます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 7-9 ライブラリの作成と使用 -s 保存されたシンボルテーブルを再生成します。 --sizes library 内のメンバごとに、Code、RO Data、RW Data、ZI Data、Debug の サイズの一覧を表示します。以下に例を示します。 Code 464 3356 3820 RO Data 0 0 0 RW data 0 0 0 ZI Data 0 10244 10244 Debug 8612 11848 20460 Object Name app_1.o app_2.o TOTAL -T 抽出されたファイルのライブラリ名がファイルシステムでサポートされ る長さよりも長い場合、ファイル名を短縮します。標準の設定では、名 前の長すぎるファイルを抽出すると、エラーが生成されます。診断メッ セージが書き込まれ、そのファイルは抽出されません。 -u 古いファイルを更新します。-r オプションと組み合わせて使用すると、 library 内のファイルは、対応するファイルの更新日がライブラリ内の ファイルの更新日と同じか、それよりも新しい場合にのみ置き換えられ ます。 --via option_file option_file からオプションを取得するようライブラリアンに指示しま す。via ファイルの記述方法の詳細については、RealView Compilation Tools v3.0 Compiler and Libraries Guide を参照して下さい。 -v 詳細な出力を行います。 出力の内容は、他に使用されているオプションによって異なります。 -d、-r、または -x ライブラリの作成、構成ファイル、保守に関する情報など、 ファイルごとに詳細な情報が書き込まれます。 7-10 -p ファイルの内容を stdout に書き込む前に、ファイルの名前が 標準出力に書き込まれます。 -t ライブラリ内のファイルに関する詳細な情報が出力されます。 -x 各ファイルが抽出される前にファイル名が出力されます。 --vsn 標準エラーにバージョン番号を出力します。 -x file_list 内のファイルを library から抽出します。library の内容は変 更 さ れ ま せ ん。フ ァイルのオペラ ンドが指定さ れていない場 合は、 library 内のすべてのファイルが抽出されます。library から抽出された ファイルの名前が、デスティネーションディレクトリでサポートされて いる長さよりも長い場合の結果は定義されていません。 --zs シンボルテーブルを表示します。 --zt 出 library 内のメンバのサイズとエントリポイントの一覧を出力します。 力形式については、--sizes および --entries を参照して下さい。 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ ライブラリの作成と使用 注 通常の処理には、オプション -a、-b、-C、-i、-m、-T、-u、および -v は必要ありません。 ARM ツールではシンボルテーブルのないライブラリを使用できないため、ライブラリ の順序に関連するオプション(-a、-b、-i、-m など)は通常の処理には関係がありませ ん。シンボルテーブルがある場合、ライブラリの順序は重要ではありません。ただし、 同じコマンドラインで -a と -b (または -i)を指定した場合は、優先順位に関する規 則を確認して下さい。 実際には、ライブラリは更新されるよりも再ビルドされることの方が多いため、ライ ブラリの更新に関するオプション(-C および -u)を使用することはほとんどありま せん。 7.3.2 コマンドラインオプションの順序 一般的に、コマンドラインオプションは任意の順序で使用できます。ただし、その結 果がコマンドラインで組み合わされる他の関連オプションによって異なるオプション もあります。 オプションが同じコマンドラインにある前のオプションをオーバーライドする場合、 最後に指定されたオプションが優先されます。この規則に従っていないオプションに ついては、そのことが説明されています。--show_cmdline オプションを使用すると、ラ イブラリアンがどのようにコマンドラインを処理したかを確認できます。コマンドは 正規化されて表示されます。また、via ファイルの内容は展開されます。 注 最新リリースの RVCT では、armar の各コマンドラインオプションの前に - を指定する 必要があります。これは、以前のリリースからの変更点です。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 7-11 ライブラリの作成と使用 7.3.3 armar の使用例 例 7-1 から 例 7-8(7-13 ページ)は、構文の例を示しています。 例 7-1 新しいライブラリの作成とすべてのオブジェクトファイルの追加 armar --create mylib *.o 例 7-2 テーブルの内容の一覧の表示 armar -tv mylib 例 7-3 シンボルテーブルの一覧の表示 armar --zs mylib 例 7-4 ファイルの追加(または置換) armar -r mylib obj1.o obj2.o obj3.o ... armar -ru mylib k*.o 例 7-5 指定された位置でのファイルの追加(または置換) armar -r -a obj2.o mylib obj3.o obj4.o ... 例 7-6 ファイル群の抽出 armar -x mylib k*.o 7-12 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ ライブラリの作成と使用 例 7-7 ファイル群の削除 armar -d mylib sys_* 例 7-8 ライブラリの結合とファイルの追加(または置換) armar -r mylib my_lib.a other_lib.a obj1.o obj2.o obj3.o ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 7-13 ライブラリの作成と使用 7-14 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ 第8章 fromelf ユーティリティの使用 本章では、RealView® Compilation Tools (RVCT)付属の ARM® fromelf ソフトウェア ユーティリティについて説明します。本章は以下のセクションから構成されています。 • fromelf について(P. 8-2) ARM DUI 0206GJ • fromelf のコマンド構文(P. 8-3) • fromelf の使用例(P. 8-13) Copyright © 2002-2006 ARM Limited. All rights reserved. 8-1 fromelf ユーティリティの使用 8.1 fromelf について ARM リンカによって生成された Executable Linkable Format fromelf ユーティリティでは、 (ELF)イメージファイルを、メモリへの直接ロードや ROM ツールに適した他の形式に 変換します。また、fromelf ユーティリティを使用すると、ELF オブジェクトに関する さまざまな情報を表示したり、その情報を含むテキストファイルを生成することもでき ます。 fromelf ユーティリティは、以下の形式のイメージを出力します。 • プレーンバイナリ形式 • Motorola 32 ビット S レコード形式 • Intel Hex 32 ビット形式 • バイト指向(Verilog メモリモデル)16 進形式 • ELF 形式。ELF 形式で再保存できます。例えば、デバッグ ELF イメージを非デ バッグ ELF イメージに変換できます。 また、fromelf ユーティリティを使用すると、逆アセンブルの出力やシンボルリストな どの入力ファイルに関する情報を標準出力(stdout)やテキストファイルに出力するこ ともできます。 8.1.1 イメージの構造 fromelf ユーティリティを使用すると、ELF 形式のファイルを他の形式に変換できま す。--base オプションを使用して Motorola S レコード形式または Intel Hex 形式の出力 のベースアドレスを変更する場合を除き、イメージの構造やアドレスを変更すること はできません。また、スキャッタローディングされる ELF イメージを、別の形式の非 スキャッタローディングのイメージに変換することはできません。構造やアドレスに 関する情報は、すべてリンク時にリンカに渡す必要があります。 8-2 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ fromelf ユーティリティの使用 8.2 fromelf のコマンド構文 このセクションでは、fromelf ユーティリティのコマンド構文とオプションについて説 明します。 fromelf [--base n] [--diag_style arm|ide|gnu] [--diag_suppress taglist] [--expandarrays] [--fieldoffsets [--select select_options ]] [--help] [--no_linkview] [memory_config] [--no_comment_section] [--no_debug] [--debugonly] [--no_symbolversions] [--text | code_output_format] [--vsn] [--output output_file] input_file 各パラメータには以下の意味があります。 --base n このオプションを指定すると、Motorola S レコード形式と Intel Hex ファイル形式の出力のベースアドレスを指定できます。このオプ ションは、出力形式として、--m32、--m32combined、--i32、また は --i32combined が指定されている場合にのみ使用できます。 ベースアドレスは以下のいずれかの方法で指定できます。 • 10 進数値(例:--base 0) • 16 進数値(例:--base 0x8000) 出力ファイル内にエンコードされるすべてのアドレスは、ベース アドレス n で開始されます。--base オプションが指定されてい ない場合、ベースアドレスはロード領域のアドレスから取得され ます。 注 複数のロード領域が存在する場合、各出力ファイルに --base の値 が使用されます。つまり、この値によって、すべてのロード領域 のアドレスがオーバーライドされます。 --diag_style arm|ide|gnu 警 告 メ ッ セ ー ジ や エ ラ ー メ ッ セ ー ジ の 形 式 を 変 更 し ま す。 --diag_style arm が標準の設定です。--diag_style gnu を指定す ると、gcc から返される形式になり、--diag_style ide を指定する と Microsoft Visual Studio から返される形式になります。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 8-3 fromelf ユーティリティの使用 --diag_suppress taglist このオプションを使用すると、指定されたタグを含むすべての診 断メッセージを無効にできます。 このオプションには、非表示にする必要がある診断メッセージの 番号をコンマで区切ったリストを指定する必要があります(複数 のタグを指定できます)。例えば、番号 1293 と 187 の警告メッセー ジを非表示にするには、以下のコマンドを使用します。 fromelf --diag_suppress 1293,187 ... メッセージを非表示にするには、fromelf の接頭文字 Q を使用す ることもできます。以下に例を示します。 fromelf --diag_suppress Q1293,Q187 ... 接頭文字の使用は省略できます。ただし、接頭文字を含める場合 は、fromelf 識別文字と一致する必要があります。別の接頭文字 が見つかると、そのメッセージ番号は無視されます。 --fieldoffsets このオプションを指定すると、アセンブリ言語の EQU ディレク ティブのリストが標準出力(stdout)に出力されます。このディ レクティブによって、C++ のクラスや C の構造体のフィールド名 は、そのクラスまたは構造体のベースからのオフセットを表すよ うになります。入力 ELF ファイルは、再配置可能なオブジェクト またはイメージです。 -o を使用すると、出力がファイルに転送されます。armasm で INCLUDE コマンドを使用すると、生成されたファイルをロード し、C++ クラスおよび C 構造体メンバにアセンブリ言語から名 前でアクセスできます。armasm の詳細については、RealView Compilation Tools v3.0 Assembler Guide を参照して下さい。 注 このオプションには以下の制限があります。 • ソースファイルにデバッグ情報がない場合は使用できま せん。 • code_output_format と組み合わせて使用することはできま せん。 8-4 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ fromelf ユーティリティの使用 このオプションを指定すると、構造体に関するすべての情報が出 力されます。構造体のサブセットに関する情報を出力するには、 --select select_options を使用します。 armasm で入力ファイルとして指定できるファイルを生成する必 要がない場合は、--text -a オプションを使用して、表示されるア ドレスを読みやすい形式にすることができます。-a オプションを 指定すると、アドレスは再配置可能なオブジェクト内には存在し ないため、イメージ内の構造体とスタティックデータのアドレス 情報のみが出力されます。 注 fromelf --fieldoffsets を指定する必要がある場合は、 --no_debug を使用しないで下さい。デバッグ情報を持たないイメージを生成 した場合、fromelf ユーティリティには、以下の制限があります。 • • イメージを別の形式のファイルに変換できません。 分かりやすい逆アセンブルリストを生成できません。 --select select_options --select select_options を --fieldoffsets または --text -a のい ずれかのオプションと組み合わせて使用すると、オプションリス ト内のパターンに一致するフィールドのみを出力または表示で きます。 複数のフィールドを選択する場合は、以下のように特殊文字を使 用します。 • リスト内のオプションを a*,b*,c* のようにコンマ(,)で 結合します。 • ワイルドカード文字(*)を使用すると、任意の名前と一致 させることができます。 • ワイルドカード文字(?)を使用すると、任意の一文字と一 致させることができます。 • インクルードするフィールドは、select_options のストリ ングの前に + を付けて指定します。これが標準の設定です。 • 除外するフィールドは、select_options ストリングの前に ~ を付けて指定します。 Sun Solaris または Red Hat Linux 環境で特殊文字を使用する場合 は、シェルによって選択範囲が拡大されないように、これらのオ プションを引用符で囲む必要があります。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 8-5 fromelf ユーティリティの使用 --help このオプションを指定すると、ヘルプと用法に関する情報を表示 できます。このオプションが指定されている場合は、他のコマン ドラインオプションは無視されます。また、パラメータを指定せ ずに fromelf を呼び出した場合も、同じ情報が表示されます。 memory_config このオプションを指定すると、複数のメモリバンク用に複数の ファイルが出力されます。 memory_config の形式は --widthxbanks です。各パラメータには 以下の意味があります。 width ターゲットメモリシステムにおけるメモリの幅を指 定します(8 ビット、16 ビット、32 ビット、または 64 ビット)。 banks ターゲットメモリシステム内のメモリバンクの数を指 定します。 有効な設定は以下のとおりです。 --8x1 --8x2 --8x4 --16x1 --16x2 --32x1 --32x2 --64x1 複数の設定が指定されている場合、fromelf は最後に指定された 設定を使用します。 イメージに 1 つのロード領域がある場合は、fromelf によって、以 下の命名規則に基づいて banks に指定された数のファイルが生成 されます。 • メモリバンクが 1 つしかない場合(banks =1)、出力ファイ ルは -o output_file 引数によって命名されます。 • 複数のメモリバンクがある場合(banks >1)、fromelf は、 banks に指定された数のファイルを生成します。ファイル名 は、output_file0 で始まり output_file banks-1 で終わりま す。以下に例を示します。 fromelf --vhx --8x2 test.axf -o test この例では、test0 および test1 という名前の 2 つのファイ ルが生成されます。 8-6 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ fromelf ユーティリティの使用 イメージに複数のロード領域がある場合、fromelf は、output_file という名前のディレクトリを作成し、load region0 から load region banks-1 までの名前が付いた、各ロード領域用に個別のバ ンクファイルを生成します。 width で指定されたメモリの幅によって、イメージから読み出さ れる情報と、ファイルに書き込まれる情報のサイズが決まりま す。最初に読み出される情報は、最初のファイル(output_file0) に割り当てられ、次に読み出される情報は次のファイルに割り当 てられます。読み出される情報が最後のファイルに割り当てられ ると、割り当ては再び最初のファイルから開始されます(つまり、 割り当てはファイルの数に基づくモジュロ演算によって行われ ます)。以下に例を示します。 memory_config に --8x4 が指定されている場合は以下のようにな ります。 byte0 byte1 byte2 byte3 byte4 ... -> -> -> -> -> file0 file1 file2 file3 file0 memory_config に --16x2 が指定されている場合は以下のようにな ります。 halfword0 -> file0 halfword1 -> file1 halfword3 -> file0 ... --no_comment_section ELF 出力ファイルから .comment --elf と組み合わせて使用すると、 セクションを削除して、ファイルのサイズを縮小できます。この オプションは、ELF 形式以外の出力形式には影響しません。ター ゲットに動的にロードされ、デバッグ可能である必要がない ELF イメージについては、これらのオプションに加えて --no_debug を 指定すると、さらに ELF イメージのサイズを縮小できます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 8-7 fromelf ユーティリティの使用 --no_debug このオプションを指定すると、出力ファイルにデバッグ情報が含 まれないようにすることができます。バイナリイメージの場合 は、これが標準の設定です。--no_debug オプションが指定されて いる場合は、すべての出力形式に影響します。このオプションは、 --text -g オプションをオーバーライドします。 注 コマンドライン上に --elf が指定されていない場合、このオプ ションによって予期しない影響が生じる可能性があります。以下 のコマンドを実行すると、出力形式が指定されていないためテキ ストファイルが生成されます。 fromelf --no_debug image -o image_nodb.axf ELF 形式の出力を生成するには、以下のオプションを使用します。 fromelf --no_debug --elf image.axf -o image_ndb.axf --debugonly このオプションを --elf と組み合わせて使用すると、任意のコー ドまたはデータセクションの内容を削除できます。このオプショ ンは、出力ファイルにデバッグに必要な情報(デバッグセクショ ン、シンボルテーブル、ストリングテーブルなど)のみを含める 場合に使用します。 セクションヘッダは、シンボルのターゲットとして機能する必要 があるため保持されます。 このオプションは、ELF 形式の出力ファイルにのみ影響します。 --no_symbolversions このオプションを指定すると、シンボルバージョン管理テーブル のデコードが無効になります。詳細については、 「シンボルのバー ジョン管理」 (P. 4-22)と Base Platform ABI for the ARM Architecture [BPABI]を参照して下さい。 8-8 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ fromelf ユーティリティの使用 --no_linkview このオプションを指定すると、ELF イメージからセクションレベ ルのビュー(リンク時のビュー)が破棄され、セグメントレベル のビュー(ロード時のビュー)のみが保持されます。リンク時に おけるセクションレベルのビューを破棄することによって、以下 が削除されます。 • セクションのヘッダテーブル • セクションのヘッダストリングテーブル • ストリングテーブル • シンボルテーブル • すべてのデバッグセクション 出力に含まれるのは、プログラムのヘッダテーブルとプログラム のセグメントのみです。ELF の仕様に基づき、これらはすべてプ ログラムローダが ELF ファイル内に存在していることを前提と しているものです。 注 コマンドライン上に --elf が指定されていない場合、このオプ ションによって予期しない影響が生じる可能性があります。ELF 形式の出力を生成するには、以下のオプションを使用します。 fromelf --no_linkview --elf image.axf -o image_nlk.axf --expandarrays このオプションを指定すると、データのアドレスを出力できま す。これには、構造体内外で展開された配列を含みます。 このオプションは、--text -a と一緒に指定する必要があります。 --text このオプションを指定すると、イメージ情報をテキスト形式で出 力できます。このオプションを使用すると、ELF イメージファイ ルまたは ELF オブジェクトファイルをデコードできます。これは 標準の設定です。つまり、コードの出力形式が指定されていない 場合は、--text が使用されます。 output_file が -o オプションと一緒に指定されていない場合、イ メージ情報は標準出力(stdout)に出力されます。 出力内容を指定するには、以下のオプション(複数可)を使用し ます。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 8-9 fromelf ユーティリティの使用 -a グローバルデータアドレスとスタティックデータアド レス(構造体とユニオンの内容のアドレスも含む)を 出力します。このオプションは、デバッグ情報を含む ファイルに対してのみ使用できます。データアドレス のサブセットを出力する場合は、--select オプション を使用します。 構造体内外で展開された配列のデータアドレスを参照す るには、このテキストカテゴリと一緒に --expandarrays オプションを使用します。 -c コードを逆アセンブルします。 -d データセクションの内容を出力します。 -e オブジェクトの例外テーブル情報をデコードします。 イメージを逆アセンブルするときに、-c と組み合わせ て使用します。 -g デバッグ情報を出力します。 -r 再配置情報を出力します。 -s シンボルテーブルとバージョン管理テーブルを出力し ます。 -t ストリングテーブルを出力します。 -v イメージの各セグメントヘッダとセクションヘッダに 関する詳細情報を出力します。 -y ダイナミックセグメントの内容を出力します。 -z コードサイズとデータサイズを出力します。 これらのオプションは、--text 出力形式が指定されている場合に のみ認識されます。 code_output_format このオプションを指定すると、バイナリ形式または ELF 形式の出 力ファイルオプションを選択できます。code_output_format には 以下のいずれかを指定できます。 8-10 --bin プレーンバイナリ形式。memory_config オプションを使 用すると、このオプションで生成された出力を複数 ファイルに分割できます。 --m32 Motorola 32 ビット形式(32 ビット S レコード形式)。 このオプションを指定すると、イメージ内のロード領 域ごとに 1 つの出力ファイルを生成できます。この出 力のベースアドレスは、--base オプションを使用して 指定できます。 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ fromelf ユーティリティの使用 --m32combined Motorola 32 ビット形式(32 ビット S レコード形式)。 このオプションを指定すると、複数のロード領域を含 むイメージ用に 1 つの出力ファイルを生成できます。 この出力のベースアドレスは、--base オプションを使 用して指定できます。 --i32 Intel Hex 32 ビット形式。このオプションを指定すると、 イメージ内のロード領域ごとに 1 つの出力ファイルを 生成できます。この出力のベースアドレスは、--base オプションを使用して指定できます。 --i32combined Intel Hex 32 ビット形式。このオプションを指定すると、 複数のロード領域を含むイメージ用に 1 つの出力ファ イルを生成できます。この出力のベースアドレスは、 --base オプションを使用して指定できます。 --vhx バイト指向(Verilog メモリモデル)16 進形式。この形 式は、ハードウェア記述言語(HDL)シミュレータの メ モ リ モ デ ル へ の ロ ー ド に 適 し て い ま す。 memory_config オプションを使用すると、このオプショ ンで生成された出力を複数ファイルに分割できます。 --elf ELF 形式(ELF 形式で再保存)。このオプションを使用 すると、デバッグ ELF イメージを非デバッグ ELF イ メージに変換できます。 fromelf に --bin、--m32 、--i32、または --vhx のいずれかのオ プションを指定して複数のロード領域を含む ELF イメージを バイナリ形式のイメージに変 換した場合、fromelf によって output_file という名前の出力ディレクトリが作成され、入力 イメージに含まれるロード領域ごとにバイナリ出力ファイルが 1 つずつ生成されます。fromelf は、これらの出力ファイルを output_file ディレクトリに配置します。 --m32combined または --i32combined のいずれかのオプションを 使用して複数のロード領域を含む ELF イメージを変換すると、 fromelf によって output_file という名前の出力ディレクトリが 作成され、入力イメージに含まれるすべてのロード領域用の 1 つ の バ イ ナ リ 出 力 フ ァ イ ル が 生 成 さ れ、こ の 出 力 フ ァ イ ル は output_file ディレクトリに配置されます。 ELF イメージは、複数のロード領域を定義しているスキャッタ ローディング記述ファイルを使用してビルドされた場合などに、 複数のロード領域を保持します。 ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 8-11 fromelf ユーティリティの使用 --vsn fromelf ユーティリティのバージョン情報を表示します。 --output output_file このオプションを指定すると、出力ファイルまたは出力ディレク トリの名前(複数の出力ファイルが作成される場合)を指定でき ます(詳細については、text_output_format と code_output_format の説明を参照して下さい)。--text 出力オプションでは出力ファ イルを指定する必要はありませんが、それ以外の場合は必ず出力 ファイルを指定する必要があります。 input_file 変換する ELF ファイルを指定します。 fromelf は、ARM 実行可能 ELF ファイルと ARM オブジェクト ELF ファイル(.o)のみを処理できます。input_file が複数のロー ド領域を含むスキャッタローディングされるイメージであり、そ の出力形式に --bin、--m32、--i32、または --vhx のいずれかが指 定されている場合には、fromelf によって各ロード領域用に個別 のファイルが生成されます。 input_file が複数のロード領域を含むスキャッタローディング されるイメージであり、その出力形式に --m32combined または --i32combined のいずれかが指定されている場合、fromelf により すべてのロード領域を含む 1 つのファイルが作成されます。 8.2.1 コマンドラインオプションの順序 一般的に、コマンドラインオプションは任意の順序で使用できます。ただし、その結 果がコマンドラインで組み合わされる他の関連オプションによって異なるオプション もあります。 オプションが同じコマンドラインにある前のオプションをオーバーライドする場合、 最後に指定されたオプションが優先されます。この規則に従っていないオプションに ついては、そのことが説明されています。--show_cmdline オプションを使用すると、 fromelf ユーティリティがどのようにコマンドラインを処理したかを確認できます。コ マンドは正規化されて表示されます。また、via ファイルの内容は展開されます。 8-12 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ fromelf ユーティリティの使用 8.3 fromelf の使用例 このセクションでは、イメージ形式を変更したり、ELF ファイルから情報を抽出する 場合の fromelf ユーティリティの使用例を紹介します。 注 Sun Solaris または Red Hat Linux 環境でワイルドカード文字(*、?、~ など)を使用する 場合は、シェルによって選択範囲が拡大されないように、これらのオプションを引用 符で囲む必要があります。 例えば、「’*, ~*.*’」ではなく「*, ~*.*」と入力します。 このセクションでは、以下の内容について説明します。 • プレーンバイナリファイルの生成 • 逆アセンブル • アセンブリ言語の EQU としてフィールドオフセットの一覧を出力 • • 8.3.1 スタティックデータのアドレス一覧を出力(P. 8-14) デバッグ有効からデバッグ無効への変換(P. 8-15) プレーンバイナリファイルの生成 ELF ファイルをプレーンバイナリファイル(.bin)に変換するには、以下のように入 力します。 fromelf --bin -o outfile.bin infile.axf 8.3.2 逆アセンブル ELF ファイルの逆アセンブルリストを標準出力(stdout)に出力するには、以下のよう に入力します。 fromelf -c infile.axf 逆アセンブルされた ELF ファイルとシンボルテーブルを含むプレーンテキストファイ ルを生成するには、以下のように入力します。 fromelf -c -s -o outfile.lst infile.axf ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 8-13 fromelf ユーティリティの使用 8.3.3 アセンブリ言語の EQU としてフィールドオフセットの一覧を出力 inputfile.o ファイル内にあるすべての構造体のすべてのフィールドオフセットが含 まれた一覧を標準出力(stdout)へ出力するには、以下のように入力します。 fromelf --fieldoffsets inputfile.o inputfile.o ファイル内で、名前が p で始まる構造体のすべてのフィールドオフセット が含まれた一覧を outputfile.a へ出力するには、以下のように入力します。 fromelf --fieldoffsets --select p* -o outputfile.a inputfile.o inputfile.o ファイル内で、tools または moretools という名前の構造体のすべての フィールドオフセットが含まれた一覧を outputfile.a へ出力するには、以下のように 入力します。 fromelf --fieldoffsets --select tools.*, moretools.* -o outputfile.a inputfile.o inputfile.o ファイル内の構造体 tools の構造体フィールド top の中にあり、名前が number で始まる構造体フィールドのすべてのフィールドオフセットが含まれた一覧を outputfile.a に出力するには、以下のように入力します。 fromelf --fieldoffsets --select tools.top.number* -o outputfile.a inputfile.o 8.3.4 スタティックデータのアドレス一覧を出力 すべてのグローバルデータ変数とスタティックデータ変数、すべての構造体フィール ドのアドレス一覧を標準出力(stdout)に出力するには、以下のように入力します。 fromelf --text -a --select * infile.axf 構造体のみの選択 inputfile.axf に含まれるすべての構造体のアドレスを保持し、グローバルデータ変数 またはスタティックデータ変数に関する情報は保持しないテキストファイルを生成す るには、以下のように入力します。 fromelf --text -a --select *.* -o strucaddress.txt infile.axf ネストされた構造体のみの選択 ネストされた構造体のアドレスのみを含むテキストファイルを生成するには、以下の ように入力します。 fromelf --text -a --select *.*.* -o strucaddress.txt infile.axf 8-14 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ fromelf ユーティリティの使用 変数のみの選択 inputfile.axf に含まれるすべてのグローバル変数またはスタティックデータ変数の 情報を保持し、構造体のアドレスは保持しないテキストファイルを生成するには、以 下のように入力します。 fromelf --text -a --select *, ~*.* -o strucaddress.txt infile.axf 8.3.5 デバッグ有効からデバッグ無効への変換 --debug オプションを指定して生成した ELF ファイルから --no_debug オプションを 使用したときと同じ内容の新しい出力ファイルを生成するには、以下のように入力し ます。 fromelf --no_debug --elf -o outfile.axf infile.axf ARM DUI 0206GJ Copyright © 2002-2006 ARM Limited. All rights reserved. 8-15 fromelf ユーティリティの使用 8-16 Copyright © 2002-2006 ARM Limited. All rights reserved. ARM DUI 0206GJ
© Copyright 2025 Paperzz