HP OpenVMS Systems Documentation |
| 前へ | 次へ | 目次 | 索引 |
Linker デバッグ修飾子の /TRACEBACK,/DEBUG,および /DSF を指定すると,下記のフラグがイメージ・アクティベータ用に設定されます。これらのフラグは,タグ値 DT_VMS_LNKFLAGS の下で動的セグメントに設定されます。 /TRACEBACK,/DEBUG および /DSF 修飾子の意味は,Alpha の Linker から変更されていませんが,フラグの意味と名称が変更されています。
| フラグ | 意味 |
|---|---|
| VMS_LF_IMGSTA | イメージの実行は, SYS$IMGSTA を呼び出すことで開始されます。イメージ・アクティベータは,転送ベクタ (従来の VMS 形式)の最初のアドレスとして SYS$IMGSTA をインクルードします。 |
| VMS_LF_CALL_DEBUG | SYS$IMGSTA は,デバッガを呼び出すかどうかを判断するためにこのフラグをチェックします。 |
| VMS_LF_TBK_IN_IMG | トレースバック・レコードはイメージ・ファイル内に存在します。 |
| VMS_LF_DBG_IN_IMG | デバッグ情報はイメージ・ファイル内に存在します。 |
| VMS_LF_TBK_IN_DSF | トレースバック・レコードは DSF ファイル内に存在します。 |
| VMS_LF_DBG_IN_DSF | デバッグ情報は DSF ファイル内に存在します。 |
フラグは,次の表に従って設定されます。
| 修飾子 | IMGSTA | CALL_ DEBUG |
TBK_IN _IMG |
DBG_IN _IMG |
TBK_IN _DSF |
DBG_IN _DSF |
|---|---|---|---|---|---|---|
| /NoTrace/NoDebug
/NoDSF |
0 | 0 | 0 | 0 | 0 | 0 |
|
/Trace/NoDebug
/NoDSF |
1 | 0 | 1 | 0 | 0 | 0 |
| /NoTrace
/Debug
/NoDSF |
1 | 1 | 1 | 1 | 0 | 0 |
|
/Trace
/Debug
/NoDSF |
1 | 1 | 1 | 1 | 0 | 0 |
| /NoTrace /NoDebug
/DSF |
0 | 0 | 0 | 0 | 1 | 1 |
|
/Trace /NoDebug
/DSF |
1 | 0 | 1 | 0 | 1 | 1 |
| /NoTrace
/Debug
/DSF |
1 | 1 | 1 | 0 | 1 | 1 |
|
/Trace /Debug
/DSF |
1 | 1 | 1 | 0 | 1 | 1 |
次の表は,SYMBOL_TABLE や SYMBOL_VECTOR オプションを使用しないイメージのリンク操作で,どのような場合にグローバル・シンボル定義が書き込まれるかを示します。
| 修飾子 | イメージのグローバル・シンボル | DSF ファイルのグローバル・シンボル |
|---|---|---|
| /NoTrace/NoDebug/NoDSF | 0 | 0 |
| /Trace/NoDebug/NoDSF | 0 | 0 |
| /NoTrace /Debug/NoDSF | 1 | 0 |
| /Trace /Debug/NoDSF | 1 | 0 |
| /NoTrace/NoDebug /DSF | 0 | 1 |
| /Trace/NoDebug /DSF | 0 | 1 |
| /NoTrace /Debug /DSF | 0 | 1 |
| /Trace /Debug /DSF | 0 | 1 |
7.1.2 OpenVMS I64 システムでのリンクの特徴
以下の項では,I64 システムでイメージをリンクする際の I64 プラットフォームに特有の事項について説明します。トピックは,次のとおりです。
一部の HP コンパイラは,呼び出し元や呼び出し先のルーチンで複数のモジュールにわたる汎用レジスタの使い方に一貫性があることが確認できるように,呼び出しリンケージ情報を生成します。リンケージ情報は,汎用レジスタ 0 〜 31 についてだけ生成されます。リンケージ情報に問題がある場合には,衝突が発生しています。
Linker がリンケージの衝突を検出した場合に表示される警告メッセージの例を次に示します。
%ILINK-W-LNKGERR, linkage to routine X is not compatible with
linkage of caller
calling module: MOD_SRC
file: DISK:[DIR]SOURCE.OBJ;1
target module: MOD_TARG
file: DISK:[DIR]TARGET.OBJ;1
source type of JSB to target type of CALL
register AI not provided (needed at target)
register GP not provided (needed at target)
IA64 register R19 (Alpha R21) -- call=PRESERVE, target=VOLATILE
|
ソース情報とターゲット情報に続いて,警告メッセージが表示される原因となった衝突の原因を示すメッセージが表示されます。ターゲット・ルーチンでは引数情報を必要としているのに,呼び出し元では引数情報レジスタ (AI) に引数情報を設定していない場合には,Linker は上記の例のようなメッセージを出力します。
また,必要な情報が欠けている場合の他に,一貫性や互換性がない方法で汎用レジスタを使った場合にも,リンケージの衝突が発生することがあります。リンケージ情報には,次のような,汎用レジスタに関するレジスタ・ポリシーが含まれています。
リンケージ呼び出し規則のレジスタ・ポリシーは,次のとおりです。
| Intel® Itanium® レジスタ | ポリシー |
|---|---|
| R2 | Volatile |
| R3 | Scratch |
| R4 - R7 | Preserve |
| R8 - R9 | Output |
| R10 -R11 | Scratch |
| R12 - R18 | Volatile |
| R19 - R24 | Scratch |
| R26 - R31 | Scratch |
プロシージャ呼び出し規則では CALL メカニズムが使われ,グローバル・ポインタ (GP) の値と AI レジスタには引数情報が格納されます。
次の表では,呼び出し元のレジスタ・ポリシー (列の見出し) とターゲット・ルーチンのレジスタ・ポリシー (行の見出し) の間で互換性があるポリシーを示しています。
| 呼び出し元 | ターゲット | |||
|---|---|---|---|---|
| Volatile | Scratch | Output | Preserve | |
| Volatile | X | |||
| Scratch | X | X | ||
| Output | X | X | ||
| Preserve | X | |||
前のサンプル・メッセージを考えます。
IA64 register R19 (Alpha R21) - call-PRESERVE, target=VOLATILE |
このメッセージでは,Intel® Itanium® レジスタ R19 は,呼び出し元では "Preserve" のレジスタ・ポリシーを持っていますが,ターゲット・ルーチンでは "Volatile" のレジスタ・ポリシーを持っています。上記の表に従えば,R19 は呼び出し元とターゲット・ルーチンの間で互換性がありません。
また,ルーチン間の呼び出しメカニズムにも互換性がありません。ターゲット・ルーチンでは CALL メカニズムが使用されることを期待しているにもかかわらず,呼び出し元ではターゲット・ルーチンへの JumptoSuBroutine (JSB) を実行しているからです。
Intel® Itanium® レジスタの中には固有のポリシーを設定しなければならないものがあります。これらのレジスタに正しいポリシーが設定されていない場合には,Linker は,ターゲット・リンケージが不正であることを示す警告メッセージ (1),または呼び出し元が不正であることを示すメッセージ (2) を出力します。
(1) %ILINK-W-INVLNKG, invalid target linkage for symbol INV_LNKG (2) %ILINK-W-INVRLNKG, invalid call linkage for symbol INV_LNKG |
次の表に固有のポリシーを持つ Intel® Itanium® の汎用レジスタを示します。
| Intel® Itanium® レジスタ | ポリシー |
|---|---|
| R2 | Volatile |
| R12 〜 R18 | Volatile |
異なる言語間で呼び出しを実行 (たとえば,IMACRO から BLISS を呼び出す) した場合に, OpenVMS の呼び出し規則が Alpha システムと I64 システムで異なるときに,衝突が発生します。 Intel® Itanium® 版の呼び出し規則では,デフォルトで保存されるレジスタの数が少なくなっています。そのため,ターゲット・ルーチンで保存されるレジスタと保存されないレジスタについての前提があります。
リンケージ文の不一致も Linker が警告メッセージを生成する原因になります。たとえば,呼び出し元のルーチンがレジスタ R12 〜 R15 (Alpha のレジスタ番号) が保存されることを期待しているのに,ターゲットが保存しない場合には,Linker はレジスタ R20,R21,R30,および R31 にリンケージの問題があることを示し,括弧内に Alpha のレジスタ番号も表示します。
また,レジスタを使っている関数でレジスタが正しく宣言されていない場合にも,問題が発生する可能性があります。たとえば,戻り値のためのレジスタに OUTPUT ではなく,NOPRESERVE を宣言しているような場合です。
このような衝突の可能性がある部分を修正するには,Linker が指摘するすべてのリンケージの定義と宣言を調べて,これらの問題点を修正し,問題点のないリンク操作が実行できるようにします。 Linker はこれらの問題を警告として扱うので,イメージの完了コードのステータスに SUCCESS は設定されません。共有イメージの場合は,これは,問題がある共有イメージとリンクされるイメージには,SUCCESS 以外の完了ステータスが与えられることを意味します。
7.1.2.2 縮小浮動小数点モデルを使ってコンパイルしたイメージについての留意事項
OpenVMS I64 システムでは,縮小浮動小数点モデルを使用しているイメージは,割り込みが発生した際の実行速度が速くなります。これは,割り込みが発生した際に,限定された数の浮動小数点レジスタだけを保存し復元すればよいからです。整数演算でも浮動小数点レジスタを使う場合があることに注意してください。イメージを構成するすべてのオブジェクト・モジュールを縮小浮動小数点モデルでコンパイルした場合にだけ,生成されたイメージを縮小浮動小数点モードで実行できます。 Linker マップ・ファイルの「Object and Image Synopsis」セクションには,モジュールが縮小浮動小数点モデルかどうかが表示されます。
7.1.2.3 ELF グループおよび UNIX スタイルの弱いシンボルとリンクする場合の留意事項
Intel C++ コンパイラでは,ELF (Executable and Linking Format) グループ (すなわち COMDAT) と UNIX スタイルの弱いシンボルを使用できるようになったため, Linker と Librarian はそれらを正しく処理する必要があります。
オブジェクト・モジュール内の ELF グループは,変数とプロシージャの定義を含む,一時的なコードとデータのコントリビューションと見なすことができます。 C++ コンパイラは C++ のテンプレートにこの機能を利用します。 C++ コンパイラは単にテンプレート (グループ) のためのコードとデータを生成します。そのような環境では,複数のオブジェクト・モジュールが複数の同一のコントリビューション (コードとデータが同じ) を持つことになります。イメージの場合は,Linker が,各グループから 1 つのコントリビューションを選択します。そのため,複数の同一グループを持つオブジェクト・モジュールを複数リンクすると,グループごとにコードとデータの 1 つのインスタンスがイメージに取り込まれます。
ELF グループは,名前を持っており,それはグループ署名とも言われます。グループは,名前が同じであれば,同一と見なされます。シンボルはグループに属することができ,そのようなシンボルをグループ・シンボルと言います。
通常どおり,グループ・シンボルは定義や参照に使用することができます。 UNIX スタイルの弱い定義は,VMS スタイルの弱い定義 (Alpha と VAX) とは異なり,重複して定義することができます。 UNIX スタイルの弱い参照は,Alpha および VAX スタイルの参照と似ていて,未解決の場合にエラーや警告は表示されません。
ELF グループの UNIX スタイルの弱いシンボルでは,特定のグループの最初に出現したシンボルを,定義インスタンスとして扱います。そして,そのグループの他の部分に出現する UNIX スタイルの弱いシンボルでその後に検出された定義は,すべて最初のインスタンスへの参照と見なされます。 UNIX スタイルの弱いシンボルは,本質的に一時的なシンボルです。弱いシンボルが存在し,リンクするその他のモジュールやイメージに強い定義が存在しない場合には,最初に出現した UNIX スタイルの弱いシンボルが,定義インスタンスと見なされます。
強い定義は,UNIX の弱い定義を上書きし,弱い定義は参照となります。同じグループの他の UNIX の弱いシンボルも参照になります。これは問題にはなりません。強い定義も含めすべてのシンボルはコンパイラによって生成されるか,または実行時環境で定義されるからです。このメカニズムを理解すると,Linker マップを理解する手助けになります。
グループ内に定義された UNIX の弱いシンボルは,そのグループ外の弱くないシンボルによって参照できます。
マップの相互参照リストでは,UNIX の弱い定義と参照には,その前に UNIX の弱いシンボルであることを示すタグ (UNIX weak タグ) が表示されます。通常は,UNIX weak タグの付いている定義は,オブジェクト・モジュールからグループを選択した結果であることを意味します。 UNIX weak タグの付いている参照は,通常,同じグループが 2 度目に出現した結果です。 UNIX weak タグの付いている参照を持つ定義でタグが付いていないものは,通常,強い定義がオブジェクト・モジュールのグループ・シンボルを上書きした結果として発生します。相互参照テーブルのタグを見れば,シンボルを定義しているインスタンスを所有するモジュールとしてどのモジュールが選択されたかがわかります。
相互参照には,グループ署名 (つまりグループ名) はリストされません。 ANALYZE ユーティリティを使用すれば,グループに属するすべてのシンボルを知ることができます。また,Linker に /MAP/FULL=GROUP_SECTIONS 修飾子を指定することで,すべてのグループと,それらを定義しているモジュールとファイルのリストを得ることができます。
ユーザが記述したテンプレートは,共有イメージとしてリンクできます。共有イメージによって (ユニバーサルに) エクスポートされたシンボルは常に強い定義になります。強い定義は UNIX の弱い定義より優先されるため,共有イメージのコードとデータは Linker によってコントリビューションとして選択されます。OpenVMS I64 では,シンボルのグループ情報は,同じように共有イメージ内に保持されます。この場合,シンボルはすべて強い定義となるため,共有イメージからのグループはオブジェクト・モジュール内のすべての同一グループより常に優先されます。
共有イメージ内のグループとオブジェクト・モジュール内のグループには,相違点が 1 つあります。他の共有イメージに同じグループがあった場合,Linker はそのグループが 2 度目に出現したときに警告します。この場合,生成されたイメージは期待どおりの動作をしない可能性があります。グループの最初に出現したコードとデータが,定義元共有イメージ内のすべてのモジュールによって使用されます。ただし,他の場所に出現するコードとデータは,他の定義元共有イメージ内で使用されます。共有イメージをリンクする際には,テンプレートの実装に必要なすべてのグループのすべてのシンボルを必ずエクスポートしてください。そうしないと,冗長なコードとデータがイメージに組み込まれてしまったり,(前述のように) 間違ったコードとデータが使用されてしまうことになります。
以前からある OpenVMS スタイルの弱いシンボルも,従来どおり,使うことができます。
| 前へ | 次へ | 目次 | 索引 |