9.5 RVCT v3.1 と RVCT v4.0 の間でのリンカの変更点

RVCT v4.0 ではさまざまな変更が armlink に加えられました。

リンカについては、以下の点が変更されました。

ヘルパ関数

RVCT v4.0 以前のバージョンでは、ヘルパ関数は、ARM コンパイラに付属する h_tf.l などのヘルパライブラリファイルに実装されていました。すべてのヘルパライブラリのファイル名は、h_ で始まります。RVCT v4.0 では、ヘルパライブラリの必要がなくなりました。その代わりに、ヘルパ関数はコンパイラによって生成され、オブジェクトファイルの一部となります。

スキャッタファイルを使用した ARM ライブラリヘルパ関数の配置

RVCT v3.1 以前では、ヘルパ関数は、ARM コンパイラに付属するライブラリに含まれています。したがって、スキャッタファイル内の armlib および cpplib を使用して、これらのヘルパ関数のメモリ内での配置をリンカに報告することが可能でした。

RVCT v4.0 以降では、コンパイラによってオブジェクトファイルにヘルパ関数が生成されます。これらの関数は標準 C ライブラリに属さなくなりました。つまり、スキャッタファイル内の armlib および cpplib は使用できなくなりました。その代わり、ヘルパ関数は、スキャッタファイル内の *.* (i.__ARM_*) を使用して配置されます。

ヘルパライブラリを使用したリンク時の警告 L6932W

RVCT v4.0 以降では、以下のリンカの警告が表示される場合があります。

警告:L6932W:ライブラリから警告がレポートされています:ヘルパライブラリ h_xx.l の使用は廃止されます

RVCT v4.0 以前のバージョンでは、ヘルパライブラリを使用してリンクを作成する理由に、オブジェクトファイルがヘルパ関数 __ARM_switch8 を参照しているかどうかが挙げられました。これは、例えば、以下のように、--verbose オプションを使用してリンカからの詳細な出力を検証することでわかります。

Loading member object1.o from lib1.a. reference :strncmp reference :__ARM_switch8

RVCT v4.0 以降のバージョンでは、ヘルパライブラリが必要ではなくなったため、リンカの詳細な出力は以下のようになる場合があります。

Loading member object2.o from lib2.a.
… definition:__ARM_common_switch8_thumb

この場合、ヘルパ関数 __ARM_common_switch8_thumb は、ヘルパライブラリ内ではなく、オブジェクトファイル object2.o 内にあります。

RVCT v4.0 を使用している場合にリンカによる警告メッセージ L6932W が表示された場合、RVCT v4.0 ではなく、RVCT v3.1 を使用してビルドされたオブジェクトまたはライブラリを使用してリンクしている可能性があります。

リンカのステアリングファイルとシンボルの可視性

RVCT v3.1 では、シンボルの可視性は、ステアリングファイルまたは .directive コマンド IMPORT および EXPORT によってオーバーライドされました。その場合、リンカによって次のような警告メッセージが生成されました。

警告:L6780W:STV_HIDDEN の可視性は、EXPORT を介してシンボル 'hidden_symbol' から削除されました。

RVCT v4.0 では、ステアリングファイルのメカニズムがシンボルの可視性を尊重するため、STV_HIDDEN シンボルの IMPORT または EXPORT は無視されます。v3.1 の動作を復元するには、 --override_visibility コマンドラインオプションを使用します。

リンカ定義のシンボル

多くの場合、領域関連シンボルの動作は v3.1 と同じです。

セクション相対シンボル

実行領域のベースシンボルとリミットシンボルは、セクション相対になりました。$$Length シンボルには該当するセクションがないので、絶対のままです。

これは、リンカ定義シンボルが実行領域内の最も適切なセクションに割り当てられることを意味しています。以下に、この例を示します。

ExecRegion ER RO Section 1 ; Image$$ER$$Base and Image$$ER$$RO$$Base, val 0 RO Section 2 ; Image$$ER$$RO$$Limit, val Limit(RO Section 2) RW Section 1 ; Image$$ER$$RW$$Base, val 0 RW Section 2 ; Image$$ER$$Limit and Image$$ER$$RW$$Limit,              ; val Limit(RW Section 2) ZI Section 1 ; Image$$ER$$ZI$$Base, val 0 ZI Section 2 ; Image$$ER$$ZI$$Limit, val Limit(ZI Section 2)

いずれの場合も、 …$$Length シンボルの値は、 …$$Limit symbol から …$$Base シンボルを引いた値になります。

実行領域内に適切なセクションがない場合は、シンボルを保持するために、適切な種類でサイズがゼロのセクションをリンカが定義します。

変更の影響

セクション相対シンボルへの変更によって、リンカの実装におけるいくつかの特殊なケースがなくなったため、信頼性が向上しました。また、SysV と BPABI のリンクでのダイナミックな再配置も、容易に実行できるようになりました。

境界整列

…$$Limit シンボルは、4 バイト境界での整列を保証しなくなりました。シンボルが定義されているセクションのリミットが、4 バイト境界で整列されているとは限らないためです。

これは、既存のコードが、整列されているシンボル値に依存している場合に、問題になることがあります。$$Limit または $$Length が整列されている必要がある場合は、シンボル値をユーザが整列させる必要があります。

例えば、次の従来の初期化コードは、Image$$<Region_Name>$$Length がワード境界で整列されていないと失敗します。

    LDR R1,|Load$$region_name$$Base|     LDR R0,|Image$$region_name$$Base|     LDR R4,|Image$$region_name$$Length|     ADD R4, R4, R0 copy_rw_data     LDRNE  R3,[R1],#4     STRNE  R3,[R0],#4     CMP  R0,R4     BNE  copy_rw_data

以前のツールチェーンのリリースよりもシステムの初期化が複雑になっているため、独自に初期化コードを記述することはお勧めできません。ARM コンパイラツールチェーンで提供されている __main コードを使用することを推奨します。

遅延再配置

リンカに、RW 圧縮後の追加のアドレス割り当てと再配置パスが導入されました。これにより、ロードアドレスに関する、より多くの情報をリンカ定義シンボルで使用できるようになりました。

次の点に注意して下さい。

  • Load$$region_name$$Base は、C ライブラリの初期化前の region_name のアドレスです。

  • Load$$region_name$$Limit は、C ライブラリの初期化前の region_name のアドレスです。

  • Image$$region_name$$Base は、C ライブラリの初期化後の region_name のアドレスです。

  • Image$$region_name$$Limit は、C ライブラリの初期化後の region_name のリミットです。

ロード領域シンボルには、以下の特性があります。

  • セクション相対シンボルは実行アドレスのみを持つことができるため、これらは絶対シンボルです。

  • RW 圧縮が考慮されます。

  • ZI は C ライブラリの初期化前には存在しないため、ZI は含まれません。

リンカでは、 Load$$region_name$$Base の他に、以下のリンカ定義シンボルがサポートされるようになりました。

Load$$region_name$$Limit Load$$region_name$$Length Load$$region_name$$RO$$Base Load$$region_name$$RO$$Limit Load$$region_name$$RO$$Length Load$$region_name$$RW$$Base Load$$region_name$$RW$$Limit Load$$region_name$$RW$$Length
                                    
遅延再配置の制限

RW 圧縮実行領域からのすべての再配置は圧縮前に実行する必要があります。これは、リンカが圧縮データでの遅延再配置を解決できないためです。

リンカが、RW 圧縮領域 REGION から、RW 圧縮に依存するリンカ定義シンボルへの再配置を検出した場合、REGION の圧縮は無効になります。

ロード領域シンボル

RVCT v4.0 では、ロード領域でのリンカ定義シンボルを使用できるようになりました。それらは実行領域での Load$$ シンボルと同じ原則に従います。ロード領域は多くの実行領域を含む場合があるので、常に $$RO および $$RW コンポーネントを定義できるとは限りません。そのため、ロード領域シンボルは領域を全体として示すだけです。

; <Load Region Name> Load$$LR$$Load_Region_Name$$Base のベースアドレス

; ロード領域の内容の最後のバイトのロードアドレス。Load$$LR$$Load_Region_Name$$Limit

; リミット - ベース Load$$LR$$Load_Region_Name$$Length
イメージ関連シンボル

RVCT v4.0 のリンカは、これらを実行領域関連シンボルと同じように実装しています。

これらは、スキャッタファイルが使用されていない場合にのみ定義されます。そのため、これらは --sysv および --bpabi リンクモデルで使用できます。

Image$$RO$$Base  ; Image$$ER_RO$$Base Image$$RO$$Limit と等価; Image$$ER_RO$$Limit Image$$RW$$Base と等価; Image$$ER_RW$$Base Image$$RW$$Limit と等価; Image$$ER_RW$$Limit Image$$ZI$$Base と等価; Image$$ER_ZI$$Base Image$$ZI$$Limit と等価; Image$$ER_ZI$$Limit と等価
ZEROPAD とのインタラクションとのインタラクション

ZEROPAD キーワード付きの実行領域は、すべての ZI データを次のようにファイルに書き出します。

  • Image$$ シンボルは初期化後に実行アドレスを定義します。

    この場合は、ゼロバイトがファイルにあっても生成されても問題ありません。そのため、Image$$ シンボルでは、 ZEROPAD はリンカ定義シンボルの値に影響しません。

  • Load$$ シンボルは初期化前にロードアドレスを定義します。

    この場合は、ファイルに書き込まれるゼロバイトがすべて認識されます。そのため、Limit および Length は、ファイルに書き込まれるゼロバイトを考慮します。

ビルド属性

RVCT v4.0 リンカでは、ABI ビルド属性セクションの読み出しと書き込みが完全にサポートされています。リンカは wchar_tenum サイズなどのプロパティを確認できるようになりました。そのため、ビルド属性に矛盾がある古いオブジェクトのエラーをリンカが診断する場合があります。ビルド属性関連の多くのメッセージは、armlink を続行できるようにするために降格できます。

--cpu オプションを使用すると、FPU 属性を調べて、選択された CPU に組み込み FPU があるかどうかを確認するようになりました。例えば、--cpu=cortex-a8--fpu=vfpv3 を意味します。RVCT v3.1 では、--cpu オプションが使用された場合、選択された CPU のビルド属性だけが確認されました。

エラーメッセージ L6463U: 入力オブジェクトに <archtype> 命令が含まれていますが、オブジェクト属性に基づく <archtype> アーキテクチャの有効なターゲットが見つかりません。--cpu オプションを使用して特定の CPU を選択することを推奨します。 は、次のいずれかの場合に生成されます。

  • ELF ファイルには、アーキテクチャ archtype の命令が含まれているが、ビルド属性は archtype がサポートされていないことを示している。

  • リンカが既存の CPU にマップできない程度の矛盾がビルド属性にある。

--cpu オプションを設定しても失敗する場合は、オプション --force_explicit_attr がビルド属性を使ってリンカの CPU マッピングを再試行します。このビルド属性は、 --cpu=archtype から構成されます。エラーの原因がビルド属性の矛盾だけの場合は、この方法が有効です。

C ライブラリの初期化

C ライブラリ初期化コードの処理に関するリンカへの変更によって、リンカのマップファイル内に、特別な名前付きセクションが生成されるようになりました。このファイルは、 --map コマンドラインオプションによって作成されます。これらの特別な名前付きセクションは、無視してかまいません。

ARM Linux

共有オブジェクトをビルドするときに、リンカは可視性が STV_DEFAULT の未定義の参照を自動的にインポートします。これは、GCC の動作と一致します。これによって、現在は成功しているリンクが失敗する場合があります。

事前リンクのサポートによって、余分なスペースが予約されるため、イメージや共有オブジェクトのサイズが多少大きくなります。事前リンクのサポートは、 --no_prelink_support を使ってオフにできます。

シンボル可視性に関して、多数の小規模な変更が行われました。それらについては、シンボル可視性の変更点で説明しています。

RW 圧縮

一部のエラー処理コードは、RW 圧縮の情報を使用できるようにするために、後から実行されます。このため、ほとんどすべての場合に、より多くのカスタマプログラムをリンクできます。RVCT v4.0 で、より多くの RW 圧縮エラーを診断できるようにするために特例がなくなったケースが 1 つあります。

RW 圧縮された複数のインプレース実行領域は、特例ではなくなりました。次のように記述することができました。

    LR1 0x0     {         ER1 +0 { file1.o(+RW) }         ER2 +0 { file2.o(+RW) }     }

v4.0 ではこのような記述はできなくなり、ER1 が ER2 上に伸張されるというエラーメッセージがリンカによって生成されます。この変更は、リンカが次のような場合を診断できるようにするために行われました。

    LR1 0x0     {         ER1 +0 { file1.o(+RW) }         ER2 +0 { file2.o(+RO) }   ; NOTE RO not RW     }

これは、RVCT v3.1 では実行時に失敗します。

関連する参考文書
9.2 RVCT v3.1 と RVCT v4.0 の間での全般的な変更点
関連情報
RW データ圧縮を使用した最適化
リンカ定義シンボルへのアクセス
領域関連シンボル
Image$$ 実行領域シンボル
Load$$ 実行領域シンボル
C および C++ でのリンカ定義シンボルのインポート
セクション関連シンボル
ARM ライブラリヘルパ関数の配置例
実行環境の初期化とアプリケーションの実行
--bpabi リンカオプション
--cpu=name リンカオプション
--force_explicit_attr リンカオプション
--fpu=name リンカオプション
--map, --no_map リンカオプション
--override_visibility リンカオプション
--prelink_support, --no_prelink_support リンカオプション
--sysv リンカオプション
--verbose リンカオプション
EXPORT
IMPORT
実行領域の属性
非機密扱いPDF file icon PDF 版ARM DUI0530JJ
Copyright © 2010-2013 ARM.All rights reserved.