HP OpenVMS Systems Documentation |
| 前へ | 次へ | 目次 | 索引 |
本リリースの OpenVMS には, I64 システムをサポートする新しいバージョンの TCP/IP Services for OpenVMS が含まれています。
TCP/IP Services Version 5.5 は,今回リリースされる OpenVMS V8.2 でのみサポートされ,Alpha システムと I64 システムの両方で動作します。 VAX システムでは,従来どおり TCP/IP Services Version 5.3 がサポートされます。このため,クラスタ環境では,使用しているオペレーティング・システムのバージョンに合ったバージョンの TCP/IP を使用するように注意してください。クラスタ構成とサポートが保証されている組み合わせについては,『OpenVMS Cluster 構成ガイド』を参照してください。
次の新機能が,Version 5.5 に追加されました。
| Libpcap Library と TCPDUMP のアップデート | -- libpcap API のサポート -- TCPDUMP Version 3.8.3 のサポート |
| IPv6 構成のサポートと機能強化 | -- IPv6 の構成手順は機能強化され,構成オプションが増えました。 -- FailSAFE IP での IPv6 のサポート (新しい ifconfig コマンドを含む)。 -- SSH での IPv6 のサポート -- PWIP (PATHWORKS Internet Protocol) ドライバでの IPv6 のサポート |
| NTP (Network Time Protocol) のサポート | -- NTP Version 4.2.0 をサポートします。 NTP Version 3 および NTP Version 2 とは互換性がありますが, NTP Version 1 とは互換性がありません。 -- NTP Version 1 よりも優れたセキュリティを備えています。 |
TCP/IP Services V5.5 の強化された機能と不具合の修正についての詳細は,『TCP/IP Services V5.5 Release Notes』を参照してください。
なお,OpenVMS I64 対応の TCP/IP Services では,日本語版のキットは提供されません。 OpenVMS I64 上で TCP/IP Services をご利用になる場合は,英語版の TCP/IP Services をお使いください。 |
Volume Shadowing for OpenVMS におけるホスト・ベース・ミニマージ (HBMM) については,オンライン・ドキュメント『Volume Shadowing for OpenVMS におけるホスト・ベース・ミニマージ』を参照してください。『Volume Shadowing for OpenVMS ホスト・ベース・ミニマージ』では,以下のような内容について説明しています。
この章では,OpenVMS I64 システムでプログラムをリンクする前に検討すべき相違点と考慮事項の概要について説明します。主なトピックは,次のとおりです。
Linker のリリース・ノートは,『HP OpenVMS Version 8.2 リリース・ノート [翻訳版]』を参照してください。
7.1 Linker ユーティリティの新機能
Linker の目的は,イメージ(バイナリのコードとデータを含むファイル)を作成することです。OpenVMS I64 の Linker は, OpenVMS I64 オブジェクト・ファイルを受け付け OpenVMS I64 イメージを生成するという点で,OpenVMS VAX および Alpha システムの Linker とは異なります。 OpenVMS VAX および Alpha システムの Linker と同様に,作成するイメージの基本タイプは, 実行イメージ です。このイメージは, DCL コマンド行で RUN コマンドを入力することで起動できます。
さらに,OpenVMS I64 Linker は 共有イメージ も作成します。共有イメージは SYMBOL_VECTOR オプションを介してエクスポートされたプロシージャとデータの集まりで,実行イメージや他の共有イメージから呼び出すことができます。共有イメージは,実行イメージや共有イメージを作成するリンク操作で入力ファイルとして含めます。
OpenVMS I64 Linker でモジュールをリンクする際の入力ファイルの基本タイプは,オブジェクト・ファイル です。オブジェクト・ファイルは,コンパイラやアセンブラなどの言語処理プロセッサによって作成されます。これらのコンパイラによって作成されたオブジェクト・ファイルは, Intel® Itanium® アーキテクチャに固有のため, OpenVMS I64 システム上でモジュールをリンクする方法は, VAX や Alpha システム上でリンクする方法とは異なる点があります。ただし,Linker 全体で見ると,OpenVMS I64 Linker のインタフェースや機能 (たとえば,シンボルの解決,仮想メモリ割り当て,イメージの初期化) は,OpenVMS VAX および Alpha システムの Linker と類似しています。
7.1.1 OpenVMS I64 システムでのリンク時の相違点
OpenVMS I64 システムでのリンクは,OpenVMS Alpha システムでのリンクと類似していますが,相違点もあります。 OpenVMS I64 Linker では,以下の修飾子とオプションは無視されます。
OpenVMS I64 Linker では,以下の修飾子とオプションは指定できません。
OpenVMS I64 Linker でサポートされる新しい修飾子を以下に示します。
これらの修飾子とオプションについて,以降の項で説明します。
7.1.1.1 I64 ではシンボルのデータ・タイプが一致する必要がある
OpenVMS Alpha では,シンボルをデータの 1 部として定義し,あたかも関数であるかのように参照することができます。 Alpha オブジェクト言語を使用しているときには,Linker がこの状態を検出する手段がありません。
一方,OpenVMS I64 では,Linker はシンボルのデータ・タイプの不一致を検出できます。 OpenVMS I64 Linker は,関数 (FUNC),データの 1 部 (OBJECT),または不明 (NOTYPE) としてシンボルをマークする情報を受け取ります。また,Linker は,関数として定義または参照されるシンボルの関数記述子をいつ作成するかを示す再配置情報も受け取ります。
シンボル・タイプが不明でない (NOTYPE でない) 場合,シンボル・タイプは一致する必要があります。シンボルの定義側が不明としてタイプを設定した場合には,参照側のタイプを関数にすることはできません。
例,2 つのモジュール FIRST.C と SECOND.Cがある場合
FIRST.C
#include <stdio.h>
int a;
int aa;
extern int second ();
void main () {
printf ("The address of 'a' is %x\n", &a);
printf ("The address of 'aa' is %x\n", &aa);
second ();
}
SECOND.C
#include <stdio.h>
extern int a();
extern int aa();
void second () {
printf ("The address of 'a' is %x\n", &a);
printf ("The address of 'aa' is %x\n", &aa);
}
|
FIRST と SECOND をリンクすると次の情報メッセージ (シンボル記述子に基づく) と警告メッセージ (再配置情報に基づく) が Linker から出力されます。
$ link first,second
%ILINK-I-DIFTYPE, symbol AA of type OBJECT cannot be referenced as type FUNC
module: SECOND
file: DISK$USER:[JOE]SECOND.OBJ;5
%ILINK-I-DIFTYPE, symbol A of type OBJECT cannot be referenced as type FUNC
module: SECOND
file: DISK$USER:[JOE]SECOND.OBJ;5
%ILINK-W-RELODIFTYPE, relocation requests the linker to build a function
descriptor for a non-function type of symbol
symbol: A
relocation section: .rela$CODE$ (section header entry: 19)
relocation type: RELA$K_R_IA_64_LTOFF_FPTR22
relocation entry: 1
module: SECOND
file: DISK$USER:[JOE]SECOND.OBJ;5
%ILINK-W-RELODIFTYPE, relocation requests the linker to build a function
descriptor for a non-function type of symbol
symbol: AA
relocation section: .rela$CODE$ (section header entry: 19)
relocation type: RELA$K_R_IA_64_LTOFF_FPTR22
relocation entry: 4
module: SECOND
file: DISK$USER:[JOE]SECOND.OBJ;5
|
これらの情報メッセージと警告メッセージが出力されないようにするには,シンボル "A" と "AA" のタイプを関数またはデータに変更します。たとえば,FIRST.C での宣言を関数に変更します。
#include <stdio.h>
int a();
int aa();
extern int second ();
void main () {
printf ("The address of 'a' is %x\n", &a);
printf ("The address of 'aa' is %x\n", &aa);
second ();
}
int a () {
return 1;
}
int aa () {
return 1;
}
|
この変更を行えば,次のように,情報メッセージと警告メッセージは出力されなくなります。
$ link first,second $ |
他の方法としては,SECOND での "A" と "AA" への参照をデータへの参照に変更することもできます。
7.1.1.2 ベース付き CLUSTER オプションの指定は OpenVMS プラットフォームによって異なる
CLUSTER オプションにベース・アドレスを指定することは, VAX システムと Alpha システムでのみ許されます。 Alpha システムでは,ベース付き CLUSTER の指定はメイン・イメージにのみ許されます。 VAX システムでは,さらに柔軟で共有イメージでもベース付き CLUSTER が許されます。 I64 システムでは,CLUSTER オプションのベース・アドレスの指定は,すべてのイメージで許されません。
7.1.1.3 OpenVMS I64 システムでの初期化されたオーバレイ・プログラム・セクションの取り扱い
Alpha システムと VAX システムでは,オーバレイ・プログラム・セクションの一部を初期化することができます。その後発生する同じ部分への初期化では,前のモジュールによる初期値を上書きします。任意のバイトに対する最後の初期値は,リンクされるイメージのそのバイトの最終的なデータとして使用されます。
I64 システムの ELF オブジェクト言語では,プログラム・セクションの一部を初期化する Alpha および VAX のオブジェクト言語の機能が現時点では実装されていません。初期化ではセクション全体が初期化されます。そのセクションに対するその後の初期化は,ゼロでない部分の値が一致するときのみ実行されます。これは,互換性のある初期化と呼ばれます。
たとえば以下の条件では, OpenVMS I64 システムと Alpha システムで結果が異なります。
それぞれで 2 つのロングワードを宣言している 2 つのプログラム・セクションがオーバレイされます。 1 番目のプログラム・セクションは 1 番目のロングワードを, 2 番目のプログラム・セクションは 2 番目のロングワードをそれぞれゼロ以外の値で初期化します。
Alpha システムでは,Linker は, 1 番目と 2 番目のロングワードが初期化されたイメージ・セクションを作成します。 VAX および Alpha のオブジェクト言語では,セクション・サイズとそれぞれのロングワードを初期化する Text Information Relocation (TIR) コマンドが Linker に渡されます。
I64 システムでは,Linker はコンパイラからの初期化データを含むセクションを受け取ります。 ELF には TIR コマンドが存在しないため,Linker は初期化を実行しません (初期化について関知しません)。 Linker は,最後に処理したプログラム・セクションの初期値を使用してイメージ・セグメントを作成します。すなわち,リンクされた順番に従って,イメージには,1 番目または 2 番目のロングワードにゼロでない値が格納されます。 Linker はイメージを作成しますが,エラーと見なしメッセージを出力します。
I64 システムでは,Linker はすべての初期化情報を読み込み,互換性をチェックします。 2 つの初期化情報が,ゼロ以外の値で同値であれば互換性があります。初期化情報に互換性がない場合には,Linker は次のエラー・メッセージを出力します。
%ILINK-E-INVOVRINI, incompatible multiple initializations for
overlaid section
section: <section name>
module: <module name for first overlaid section>
file: <file name for first overlaid section>
module: <module name for second overlaid section>
file: <file name for second overlaid section>
|
このエラー・メッセージには,ゼロ以外の初期化がなされた最初のモジュールと互換性のない初期化が検出された最初のモジュールが表示されます。すべての互換性のない初期化がリストされるわけではないことに注意してください。 Linker が検出した最初の互換性のないモジュールが表示されるだけです。
Linker マップの Program Section Synopsis では,ゼロ以外の初期化がされた各モジュールには "Initializing Contribution" のフラグが付けられます。この情報を使用して,すべての互換性のない初期化を識別し解決してください。
次の例では,マップ・ファイルの追加情報を示します ( 例 7-1 を参照)。
$ cre one.c
int common_data[]={0,0,47,11};
[Exit]
$ cc /extern=common one
$
$ cre two.c
int common_data[]={0,0,47,11};
[Exit]
$ cc /extern=common two
$
$ cre three.c
int common_data[]={0,0,0,0,0,0,0,0};
[Exit]
$ cc /extern=common three
$
$ link/map one,two,three
.
.
.
|
例 7-1 には,上記の例のLinker マップでの Program Section Synopsis を示します。 Align および Attributes フィールドは,通常 Length フィールドに続いて表示されますが,ページ内に収まるように変更してあります。
| 例 7-1 Program Section Synopsis を示すLinker マップ |
|---|
+--------------------------+
! Program Section Synopsis !
+--------------------------+
Psect Name Module/Image Base End Length
---------- ------------ ---- --- ------
COMMON_DATA 00010000 0001001F 00000020 ( 32.)
ONE 00010000 0001000F 00000010 ( 16.)
TWO 00010000 0001000F 00000010 ( 16.)
THREE 00010000 0001001F 00000020 ( 32.)
Align Attributes
----- ------------
OCTA 4 OVR,REL,GBL,NOSHR,NOEXE, WRT,NOVEC, MOD
OCTA 4 Initializing Contribution
OCTA 4 Initializing Contribution
OCTA 4
|
次の例では,互換性のない初期化とその結果の Linker メッセージを示します。
$ cre four.c
int common_data[]={0,0,47,11,0,0,17,4};
[Exit]
$ cc /extern=common four
$
$link one,two,three,four
%ILINK-E-INVOVRINI, incompatible multiple initializations for
overlaid section
section: COMMON_DATA
module: ONE
file: DISK$USER:[JOE]ONE.OBJ;1
module: FOUR
file: DISK$USER:[JOE]FOUR.OBJ;1
|
この例は,外部共通モデルでコンパイルされています。 VMS では,デフォルトの外部モデルは,緩やかな refdef モデルです。このモデルでは,明示的初期化が 1 つのみ許されます。つまり,同一の初期化でも,重複定義の警告メッセージが出力されます。上記の例と同じソース・ファイルを使用した例を次に示します。
$ cc one
$ cc two
$ cc three
$
$ link one, two, three
%ILINK-W-MULDEF, symbol COMMON_DATA multiply defined
module: TWO
file: DISK$USER:[JOE]TWO.OBJ;2
%ILINK-W-MULDEF, symbol COMMON_DATA multiply defined
module: THREE
file: DISK$USER:[JOE]THREE.OBJ;2
|
他の互換性のない初期化に対しては,Linker は INVOVRINI エラーと MULDEF 警告の両方を出力します。そのようなモジュールでは,INVOVRINI メッセージ,MULDEF メッセージの順に出力されます。このような場合には,INVOVRINI エラーを取り除くために MULDEF 警告を解決する必要があります。
$ cc four
$
$ link one,two,three,four
%ILINK-W-MULDEF, symbol COMMON_DATA multiply defined
module: TWO
file: DISK$USER:[JOE]TWO.OBJ;2
%ILINK-W-MULDEF, symbol COMMON_DATA multiply defined
module: THREE
file: DISK$USER:[JOE]THREE.OBJ;2
%ILINK-E-INVOVRINI, incompatible multiple initializations for
overlaid section
section: COMMON_DATA
module: ONE
file: DISK$USER:[JOE]ONE.OBJ;2
module: FOUR
file: DISK$USER:[JOE]FOUR.OBJ;2
%ILINK-W-MULDEF, symbol COMMON_DATA multiply defined
module: FOUR
file: DISK$USER:[JOE]FOUR.OBJ;2
|
7.1.1.4 ELF 共通シンボルのリンク時の動作の相違点
ELF 共通シンボル (または,Alpha の緩やかな refdef シンボル) が同じシンボルの定義を含むイメージに対して選択的にリンクされるときには,I64 Linker は異なる動作をします。 Alpha では,Linker は誤ってモジュールの緩やかな refdef シンボルから定義を取り出します。 I64 Linker は,共有イメージから定義を取り出します。
たとえば,共有イメージが下記のモジュール (my_int.c) からリンクされるとします。
#include ints uint64 my_int ; $cc/extern=relaxed my_int.c $link/map/full/cross/share my_int,sys$input/opt symbol_vector=(my_int=data) |
次に別の C モジュール (x.c) が my_$int.exe に対して選択的にリンクされるとします。オブジェクトは緩やかな外部モデルでコンパイルされていることに注意してください。その結果,my_int に対して条件付き参照/定義が生成されます。
#include ints
uint64 my_int;
main()
{
my_int = 1;
return;
}
$cc/extern=relaxed x.c
$link/map/full/cross sys$input/opt
cluster=myclu,,,x.obj
my_int.exe/share/select
|
Alpha のLinker は,間違ってモジュールの条件付き定義の my_int から my_int を定義します。 I64 Linker は,正しく my_int.exe から定義を取り出します。
Alpha の Linker では,この動作に依存するプログラムを保護するために,変更は実施されていません。 I64 の Linker では,選択動作は正しく実行されます。
| 前へ | 次へ | 目次 | 索引 |