HP OpenVMS Systems Documentation |
| 前へ | 次へ | 目次 | 索引 |
プログラム自身をメモリへロックするのに SYS$LKWSET または SYS$LKWSET_64 を使用している場合には,これらを (OpenVMS Version 8.2 で導入された) LIB$LOCK_IMAGE という新しいライブラリ・ルーチンに置き換えることをお勧めします。同様に,SYS$ULWSET および SYS$ULWSET_64 も LIB$UNLOCK_IMAGE という新しいライブラリ・ルーチンに置き換えます (ただし,VAX システムで実行されるプログラムは,これらの新しいライブラリ・ルーチンを使用することはできません)。
カーネル・モードに入り,IPL を 2 より大きな値に上げるプログラムは,プログラム・コードとデータをワーキング・セット内にロックしなければなりません。コードとデータのロックが必要なのは,システムが PGFIPLHI バグ・チェックでクラッシュするのを回避するためです。
VAX システムでは通常,プログラムで明示的に参照されるコードとデータのロックだけが必要でした。 Alpha では,プログラムで参照されるコード,データ,およびリンケージ・データをロックしなければなりません。 I64 システムでは,コード,データ,ショート・データ,およびリンカで生成されたコードをロックする必要があります。ポーティングを容易にするため,また,ショート・データとリンカ生成データのアドレスはイメージ内で簡単に検出できないという理由から, Alpha と I64 の SYS$LKWSET および SYS$LKWSET_64 システム・サービスには変更が加えられています。
OpenVMS Version 8.2 では,SYS$LKWSET および SYS$LKWSET_64 システム・サービスは,渡された最初のアドレスを調べます。このアドレスがイメージの内部にある場合は,これらのサービスはイメージ全体をワーキング・セット内にロックしようとします。正常終了状態コードが返されると,システムが PGFIPLHI バグ・チェックでクラッシュすることなく,プログラムは IPL を 2 より大きな値に上げることができます。
ワーキング・セット内でイメージのロックが成功した回数を数えるカウンタが,内部 OpenVMS イメージ構造で管理されています。このカウンタは,ロックされたときに増分され,アンロックされたときに減分されます。カウンタが 0 になると,イメージ全体がワーキング・セットからアンロックされます。
特権プログラムが Alpha および I64 用であり VAX では使われない場合は,コード,データ,およびリンケージ・データを検索してこれらの領域をワーキング・セット内でロックするようなコードをすべて削除することができます。この種のコードは,LIB$LOCK_IMAGE および LIB$UNLOCK_IMAGE (OpenVMS Version 8.2 で提供) の呼び出しと置き換えることができます。これらのルーチンの方がプログラムにとって単純であり,コードの理解と保守も容易になります。
プログラムのイメージが大きすぎるために,ワーキング・セットでロックできない場合は,状態コード SS$_LKWSETFUL が返されます。この状態が返された場合は,ユーザのワーキング・セット・クォータを拡大することができます。また,イメージを 2 つの部分に分割することもできます。ユーザ・モードのコードを格納する部分と,カーネル・モードのコードを格納する共有イメージに分割します。カーネル・モード・ルーチンを開始するときに,このルーチンは LIB$LOCK_IMAGE を呼び出して,イメージ全体をワーキング・セットでロックしなければなりません。カーネル・モード・ルーチンを終了する前に,ルーチンで LIB$UNLOCK_IMAGE を呼び出す必要があります。
4.8.9.2 SYS$LCKPAG および SYS$LCKPAG_64 の使用
メモリでコードをロックするためにアプリケーションで SYS$LCKPAG あるいは SYS$LCKAPG_64 を使用している場合,このサービスの使用を再検討してください。 I64 では,このサービスはワーキング・セットのイメージ全体はロックしません。
コードが IPL を上げ,ページ・フォルトを発生することなく実行できるように,ワーキング・セットのイメージをロックしようとしているのかもしれません。 第 4.8.9.1 項 を参照してください。 LIB$LOCK_IMAGE および LIB$UNLOCK_IMAGE ルーチンについては『OpenVMS RTL Library (LIB$) Manual』を参照してください。
4.8.9.3 ターミナル・ドライバ
OpenVMS I64 のターミナル・クラス・ドライバのインタフェースは,コール・ベース・インタフェースです。これは,引数の受け渡しにレジスタを使用する OpenVMS Alpha の JSB ベースのインタフェースと大きく異なります。
OpenVMS I64 のターミナル・クラス・ドライバのインタフェースについては,『OpenVMS Terminal Driver Port Class Interface for Itanium』を参照してください。このドキュメントは以下の Web サイトで入手できます。
http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/resources |
保護されたイメージ・セクションは,通常,ユーザ作成のシステム・サービスを実装するための共有イメージで使用されます。
これらのイメージ・セクションは,ソフトウェアおよびハードウェアの機能によって保護し,特権のないアプリケーションがこれらのセクションの完全性を危うくすることがないようにします。 VAX および Alpha と I64 のハードウェアのページ保護機能の違いにより,わずかな制限が追加になりますので,保護されたイメージに対して変更が必要になる場合があります。
VAX および Alpha では,特権モード (カーネル・モードまたはエグゼクティブ・モード) で書き込み可能なデータ・セクションは,非特権 (ユーザ) モードで読み取りが可能です。そのようなページに対するハードウェア保護機能は,どのモードからも実行アクセスは許可しません。書き込み可能かつ実行可能としてリンクされた保護されたイメージ・セクションは,内部モードでの読み込み,書き込み,実行のみを許可し,ユーザモードでのアクセスは許可しません。内部モードでの書き込みが可能なデータへのユーザ・モード・アクセスも,書き込み可能セクションにコードを置くことも一般的ではないため, 1 つのセクションで両方を必要とするアプリケーションはほとんどないと考えられます。
このように VAX と Alpha では例外がありましたが, I64 では,すべての保護された書き込み可能イメージ・セクションは,ユーザ・モードでの書き込みから保護されます。保護されたイメージ・セクションに対するユーザ書き込みを許可する場合は,$SETPRT/$SETPRT_64 を使ってページ保護を変更する必要があります。
この章では,OpenVMS I64 開発環境について以下の項目を説明します。
OpenVMS I64 では,以下の言語に対して I64 のネイティブ・コンパイラが提供されています。
Alpha の Macro-64 アセンブラ・コードを OpenVMS I64 でコンパイルし実行するための機能は提供されません。
I64 コンパイラでは,VAX 浮動小数点データ・タイプを使用するためのコマンド・ライン修飾子が提供されます。 VAX Macro-32 コンパイラを除き,これらのコンパイラの詳細については, 第 6 章 を参照してください。
5.1.1 VAX MACRO-32 Compiler for OpenVMS I64
OpenVMS I64 向けの新しいプログラムの開発では,高級言語を使用することをお勧めします。 既存の VAX MACRO コードを OpenVMS I64 システム上で動作するマシン・コードに変換するための VAX Macro-32 Compiler for OpenVMS I64 を提供します。
大部分の VAX MACRO コードは,まったく変更せずにコンパイルできます。例外は以下のとおりです。
VAX MACRO プログラムの OpenVMS I64 システムへのポーティングの詳細については,『OpenVMS MACRO-32 Porting and User's Guide』を参照してください。
5.2 その他の開発ツール
I64 のネイティブ・アプリケーションの開発,デバッグ,および導入のために,コンパイラの他に複数のツールが提供されています。これらのツールについて, 表 5-1 で概要を説明します。
| ツール | 説明 |
|---|---|
| OpenVMS リンカ | OpenVMS リンカは I64 のオブジェクト・ファイルから I64 のイメージを生成します。 OpenVMS リンカの詳細については, 第 5.3 節 を参照してください。 |
| OpenVMS デバッガ | OpenVMS I64 で動作する OpenVMS デバッガには,現在の OpenVMS Alpha デバッガと同じコマンド・インタフェースが用意されています。 OpenVMS Alpha システムで提供されているグラフィカル・インタフェースは,今後のリリースで提供される予定です。 OpenVMS I64 で提供される OpenVMS デバッガの詳細については, 第 5.4 節 を参照してください。 |
| XDelta デバッガ | XDelta デバッガは,特権プロセッサ・モードや引き上げられた割り込み優先順位レベル (IPL) で動作するプログラムのデバッグ用に使用されるアドレス・ロケーション・デバッガです。 XDelta デバッガは本リリースで提供されますが, Delta デバッガはまだ提供されていません。 |
| OpenVMS Librarian ユーティリティ | OpenVMS Librarian ユーティリティは I64 ライブラリを作成します。 |
| OpenVMS Message ユーティリティ | OpenVMS Message ユーティリティを使用すると, OpenVMS のシステム・メッセージに独自のメッセージを追加することができます。 |
| ANALYZE/IMAGE | Analyze/Image ユーティリティは I64 イメージを分析できます。 |
| ANALYZE/OBJECT | Analyze/Object ユーティリティは I64 オブジェクトを分析できます。 |
| DECset | DECset はさまざまな開発ツールを盛り込んだパッケージであり, LSE (Language Sensitive Editor), DTM (Digital Test Manager), CMS (Code Management System),および MMS (Module Management System) が含まれています。この他に DECset には, PCA (Performance and Coverage Analyzer ) と SCA (Source Code Analyzer) の 2 つのツールがありますが,これらのツールは将来のリリースで提供される予定です。 |
| Command Definition ユーティリティ | Command Definition ユーティリティ (CDU) を使うと, DCL コマンドに似た構文を持つコマンドを作成できます。 |
| System Dump Analyzer (SDA) | SDA は拡張され,OpenVMS I64 システム固有の情報も表示するようになりました。 |
| Crash Log Utility Extractor (CLUE) | CLUE は,クラッシュ・ダンプの履歴と各クラッシュ・ダンプのキー・パラメータを記録し,キー情報を抽出して要約を表示するためのツールです。 |
HP OpenVMS Migration Software for Alpha to Integrity Servers は,Alpha 用のユーザ・コード・イメージを OpenVMS I64 システムで動作させるためのバイナリ・トランスレータです。このツールは,ソース・コードがすでに入手できなくなっていたり, I64 でコンパイラが利用できない場合や,他社製の製品が OpenVMS I64 にポーティングされていない場合などに便利です。なお,他社製品に対して使用する場合は,ソフトウェア保有者の許可が必要です。
HP OpenVMS Migration Software for Alpha to Integrity Servers は,DECmigrate に似た機能を提供します。 DECmigrate は,OpenVMS VAX のイメージを OpenVMS Alpha システムで動作させるためのポーティングの際に使用されたバイナリ・トランスレータです。
詳細は, 第 4.1.2.1 項 を参照してください。
5.3 モジュールのリンク
リンカの目的は,イメージ,つまりバイナリ・コードとデータが格納されているファイルを作成することです。 OpenVMS I64 に移植されているリンカは, OpenVMS VAX および Alpha のリンカと異なり, OpenVMS I64 オブジェクト・ファイルを受け付け, OpenVMS I64 イメージを作成します。 OpenVMS VAX および Alpha システムと同様に,作成されるイメージの主なタイプは 実行イメージです。このイメージは,DCL コマンド・ラインで RUN コマンドを発行することにより起動できます。
OpenVMS I64 リンカは共有イメージも作成します。共有イメージは, symbol_vector オプションでエクスポートされるプロシージャおよびデータ(それらは実行イメージや他の共有イメージから参照可能)の集合です。共有イメージは,実行イメージまたは共有イメージを作成するリンク操作で,入力ファイルとして指定されます。
モジュールをリンクする際にリンカの入力ファイルとなるのは,通常,オブジェクト・ファイルです。オブジェクト・ファイルは,コンパイラやアセンブラなどの言語プロセッサによって作成されます。これらのコンパイラで作成されるオブジェクト・ファイルは, Intel Itanium アーキテクチャ固有のものなので,OpenVMS I64 でのモジュールのリンクには, OpenVMS VAX/Alpha の場合と異なる特徴がいくつかあります。一般に,OpenVMS I64 のリンカ・インタフェースをはじめ,その他の機能 (たとえば,シンボルの解決,仮想メモリの割り当て,イメージの初期化) は, OpenVMS VAX および Alpha システムの場合と類似しています。ここでは,リンカの相違点の概要を示し, OpenVMS I64 システムでプログラムをリンクする前に確認の必要がある項目についても説明します。説明する内容は次のとおりです。
これらの機能および検討事項の詳細については,『HP OpenVMS Version 8.2 新機能説明書』を参照してください。
5.3.1 OpenVMS I64 システムでリンクする場合の相違点
OpenVMS I64 システムでのリンクは OpenVMS Alpha システムでのリンクに類似していますが,いくつかの相違点があります。 OpenVMS I64 リンカは,以下の修飾子あるいはオプションを無視します。
以下の修飾子およびオプションは,OpenVMS I64 リンカでは使用できません。
以下の新しい修飾子が OpenVMS I64 リンカでサポートされます。
これらの修飾子およびオプションのいくつかについての詳細は,『HP OpenVMS Version 8.2 新機能説明書』を参照してください。
5.3.1.1 CLUSTER オプションでのベース・アドレスの指定
VAX および Alpha では, CLUSTER オプションでのベース・アドレスの指定が可能です。 VAX では共有イメージであってもベース・クラスタを含めることが可能ですが, Alpha ではメイン・イメージのみがそのようなクラスタを構成することが可能です。 I64 では,CLUSTER オプションでのベース・アドレスの指定はどのイメージに対しても認められていません。
5.3.1.2 OpenVMS I64 での初期化済みオーバーレイ・プログラム・セクションの取り扱い
Alpha および VAX システムでは,オーバーレイ・プログラム・セクションの一部に対する初期化が可能でした。同じ部分に対して複数回初期化を行うと,前のモジュールで行われた初期化が上書きされます。リンクされるイメージで,それぞれのバイトごとに,最後に実行された初期化の内容が,そのバイトの最終値として適用されます。
I64 システムの ELF (Executable and Linkable Format) オブジェクト言語は,セクションの一部を初期化するという Alpha および VAX オブジェクト言語の機能を実装していません。 I64 システムで初期化を行うと,セクション全体が初期化されます。このセクションのその後の初期化は,ゼロ以外の部分が値で一致する場合のみ実行されます。
たとえば以下の条件の場合は, OpenVMS I64 システムと Alpha システムで異なる結果が発生します。
それぞれが 2 つのロングワードを宣言する 2 つのプログラム・セクション (ELF では単にセックションと呼ぶ) がオーバーレイされた場合。最初のプログラム・セクションが最初のロングワードを初期化し, 2 番目のプログラム・セクションは 2 番目のロングワードをゼロ以外の値で初期化します。
OpenVMS Alpha システムでは,リンカは,最初のロングワードと 2 番目のロングワードが初期化されたイメージ・セクションを作成します。 VAX および Alpha オブジェクト言語は,セクションを初期化するために,セクション・サイズと TIR (Text Information Relocation) コマンドをリンカに与えます。
OpenVMS I64 システムでは,リンカは,コンパイラからの初期化データを含む事前に初期化されたイメージ・セクションを取得します。 ELF には TIR コマンドがないため,リンカは初期化は行わず,また初期化についての情報を持っていません。その後リンカは,最後に処理されたセクションを使用して初期化のためのセグメントを生成します。つまり,イメージの最初のロングワードあるいは 2 番目のロングワードのどちらかがゼロ以外の値に初期化されるかどうかは,モジュールがリンクされた順番によります。 I64 システムでは,オーバーレイされたセクションをリンカが読み取り,互換性 (初期化が同一であるか,または矛盾がないか) をチェックします。 2 つのオーバーレイ・セクションがゼロ以外の値で同一であれば,それらは互換性があります。初期化が一致していない場合は,リンカは次のようなエラーを出力します。
%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>
|
上記のメッセージでは,リンカは,ゼロ以外の初期化を行った最初のモジュール,およびそれと互換性のない初期化を行う最初のモジュールをリストします。なおこれは,互換性のないすべての初期化を含む完全なリストではありません。リンカが遭遇する最初のものにすぎません。
リンカ・マップのプログラム・セクション構文では,ゼロ以外の初期化を伴う各モジュールには "Initializing Contribution" というフラグが付けられます。この情報を使用して,すべての互換性のない初期化を識別し,解決してください。初期化済みのオーバーレイ・セクションの処理に関するさらに詳しい例と説明については,『HP OpenVMS Version 8.2 新機能説明書』を参照してください。
| 前へ | 次へ | 目次 | 索引 |