日本-日本語
日本HPホーム 製品 & サービス OpenVMS製品情報
≫  お問い合わせ


OpenVMS マニュアル


 

OpenVMS ドキュメント
ライブラリ

タイトルページ
目次
まえがき
第1章:はじめに
第2章:基本的な相違点
第3章:アプリケーションの調査
第4章:ソース・モジュールの移行
第5章:OpenVMS I64 開発環境
第6章:ポーティングの準備
第7章:その他の検討事項
付録A :アプリケーション評価チェックリスト
付録B :サポート対象外のレイヤード・プロダクト
付録C :アプリケーション固有のスタック切り換えコードの I64 へのポーティング
用語集
索引
PDF
OpenVMS ホーム

HP OpenVMS
OpenVMS Alpha から OpenVMS I64 へのアプリケーション・ポーティング・ガイド


目次 索引



アプリケーションを OpenVMS I64 に移行した後,デバッグが必要になるかもしれません。ここでは,アプリケーションのデバッグのために提供されている OpenVMS ツールについて説明します。

これらのツールの詳細については, 第 5 章第 6 章 ,および『OpenVMS デバッガ説明書』を参照してください。

4.5.1 デバッグ

OpenVMS I64 オペレーティング・システムでは,以下のデバッガが提供されます。

  • OpenVMS デバッガ
    OpenVMS デバッガはシンボリック・デバッガです。プログラムで使用されているシンボル (変数名,ルーチン名,ラベル名など) によってプログラム・ロケーションを参照できます。プログラム・ロケーションを参照するときに,メモリ・アドレスやマシン・レジスタを指定する必要はありません。
    OpenVMS Debugger は変換イメージのデバッグはサポートしていません。ただし,変換イメージを使用するネイティブ・アプリケーションのデバッグは可能です。

  • XDelta デバッガ
    XDelta デバッガはアドレス・ロケーション・デバッガです。このデバッガではアドレス・ロケーションでプログラム・ロケーションを参照しなければなりません。このデバッガは主に,特権プロセッサ・モードや割り込みレベルが高められた状態で動作するプログラムのデバッグに使用されます。 Delta デバッガはまだ提供されていません。

シンボリック・デバッガであるシステムコード・デバッガは,常駐コードやデバイス・ドライバをどの IPL でもデバッグできるものです。

4.5.2 システム・クラッシュの分析

OpenVMS では,システム・クラッシュを分析するために, System Dump Analyzer と Crash Log Utility Extractor の 2 つのツールが提供されます。

OpenVMS I64 システムの System Dump Analyzer (SDA) ユーティリティは, OpenVMS Alpha システムで提供されているユーティリティとほとんど同じです。 Crash Log Utility Extractor (CLUE) ユーティリティの機能にアクセスするための機能も含めて,多くのコマンド,修飾子,表示は OpenVMS Alpha のものと同じです。一部の表示は,OpenVMS I64 システム固有の情報も表示するように変更されています。

Alpha システムで SDA を使用するには,Alpha システムの OpenVMS 呼び出し規則について十分理解している必要があります。同様に,I64 システムで SDA を使用するには, I64 システムの OpenVMS 呼び出し規則について十分理解している必要があります。理解が十分でないと,スタックで発生したクラッシュのパターンを解読することはできません。詳細については,『OpenVMS Calling Standard』を参照してください。

Crash Log Utility Extractor (CLUE) は,クラッシュ・ダンプの履歴と各クラッシュ・ダンプのキー・パラメータを記録し,キー情報を抽出して要約するためのツールです。クラッシュ・ダンプはシステム障害が発生するたびに上書きされ,最新の障害に関する情報しか残りませんが,サマリ・クラッシュ・ヒストリ・ファイルには障害ごとの個別のリスト・ファイルが記録されるため,システム障害の永久的な記録になります。

4.6 移行したアプリケーションのテスト

移行したアプリケーションのテストを行い,移行したバージョンと Alpha バージョンの機能を比較する必要があります。

テストの最初のステップで,Alpha アプリケーションに対してテスト・ツールを実行し,アプリケーションの基準値を設定します。 第 4.3 節 を参照してください。

アプリケーションが I64 システムで動作するようになったら,以下の 2 種類のテストを行います。

  • Alpha バージョンのアプリケーションに対して使用した標準的なテスト

  • アーキテクチャが変更されたために問題が発生していないか確認するための新しいテスト



4.6.1 I64 への Alpha テスト・ツールのポーティング

移植したアプリケーションでは,新しいアーキテクチャの使用に伴う変更が含まれているため, OpenVMS I64 に移行した後でアプリケーションをテストすることは特に重要です。アプリケーションの変更によってエラーが発生するだけでなく,新しい環境に移行したことで,Alpha バージョンに潜在していた問題点が顕在化することもあります。

次の手順で,移行したアプリケーションをテストします。

  1. 移行の前に,そのアプリケーションの標準的データをすべて用意します。

  2. アプリケーションとともに Alpha 用のテスト・ツールも移行します (I64 にまだテスト・ツールがない場合)。

  3. I64 システムでテスト・ツールを検証します。

  4. 移行したアプリケーションに対して,移行したテスト・ツールを実行します。

ここでは,リグレッション・テストとストレス・テストの両方が役立ちます。同期に関するプラットフォーム間の違いをテストするには,ストレス・テストが重要です。特に,複数の実行スレッドを使用するアプリケーションの場合は,ストレス・テストが重要になります。

4.6.2 新しい I64 テスト

移行した一連のテスト・ツールによるテストは,移行したアプリケーションの機能の検証に大いに役立ちますが,移行に伴って発生する問題点を検証するためのテストも追加しなければなりません。以下のポイントに注意する必要があります。

  • コンパイラの違い

  • アーキテクチャの違い

  • 異なる言語で作成されたモジュールなどの統合



4.6.3 潜在的なバグの検出

最善を尽くしたとしても, OpenVMS Alpha システムでは問題にならなかった潜在的なバグが検出されることがあります。

たとえば,プログラムで一部の変数の初期化をしていない場合, Alpha システムでは問題にならなくても, I64 システムでは算術演算例外が発生することがあります。同様に,使用できるインストラクションやコンパイラの最適化方法が変更されたために,2 つのアーキテクチャ間で移行したときに,問題が発生することもあります。隠れているバグを取り除くのは容易ではありません。アプリケーションを移植した後,実際の運用に入る前にプログラムをテストすることが必要です。

4.7 移行したアプリケーションのソフトウェア・システムへの統合

アプリケーションを移行した後,他のソフトウェアとの相互関係によって発生する問題や,移行によって発生した問題がないか確認します。

相互運用性に関する問題の原因としては,以下の原因が考えられます。

  • OpenVMS Cluster 環境内の Alpha システムと I64 システムは,それぞれ別のシステム・ディスクを使用する必要があります。アプリケーションが適切なシステム・ディスクを参照しているかどうか,確認する必要があります。

  • イメージ名
    アーキテクチャが混在した環境では,アプリケーションが CPU に対応した適切なイメージを参照しているかどうか確認する必要があります。

    • Alpha 環境でも I64 環境でもイメージの名前は同一です。
      I64 システムで Alpha イメージを実行しようとすると,以下のようなエラー・メッセージが表示されます。

      $  run alpha_image.exe 
      %DCL-W-ACTIMAGE, error activating image alpha_image.exe 
      -CLI-E-IMGNAME, image file alpha_image.exe
      -IMGACT-F-NOT_I64, image is not an HP OpenVMS Industry Standard 64 image 
      $ 
      



4.8 特定のタイプのコードの変更

特定のコーディング手法および特定のタイプのコードは変更する必要があります。変更の必要なコーディング手法およびコード・タイプとしては以下のようなものがあります。

  • Alpha Macro-64 アセンブラ・コード
    このコードは他の言語で書き直す必要があります。

  • Alpha または VAX システムで実行するための条件付きステートメントを含むコード
    このようなコードは,I64 で実行するための条件に変更する必要があります。

  • Alpha アーキテクチャに依存する OpenVMS システム・サービスを使用しているコード

  • Alpha アーキテクチャに依存するその他の要素を含むコード

  • 浮動小数点データ・タイプを使用するコード

  • コマンド定義ファイルを使用するコード

  • スレッド,特にカスタム作成タスキングやスタック・スイッチングを使用しているコード

  • 特権コード



4.8.1 条件付きコード

ここでは,I64 に移行するときに,OpenVMS コードを条件付けする方法について説明します。このコードは,Alpha と I64 の両方を対象にコンパイルされるか,または VAX,Alpha,および I64 を対象にコンパイルされます。この後の各項で参照する ALPHA というシンボルは新しいシンボルです。しかし,EVAX というシンボルも削除されていません,必ずしも EVAX を ALPHA に置き換えなければならないわけではなく,都合の良いときに置き換えるということでかまいません。 MACRO と BLISS で使用できるアーキテクチャ・シンボルは,VAX,EVAX,ALPHA,および IA64 です。

Macro-32 ソース・ファイルの場合,アーキテクチャ・シンボルは ARCH_DEFS.MAR に定義されており,これはコマンド・ラインに指定されるプレフィックス・ファイルです。 Alpha では,ALPHA と EVAX は 1 に定義されており, VAX と IA64 は未定義です。 I64 では,IA64 は 1 に定義されており,VAX,EVAX,および ALPHA は未定義です。

以下の例は,Alpha システムと I64 システムの両方で実行できるように,Macro-32 ソース・コードを条件付けする方法を示しています。

Alpha 固有のコードの場合:

.IF DF ALPHA 
       . 
       . 
       . 
.ENDC 

I64 固有のコードの場合:

.IF DF IA64 
       . 
       . 
       . 
.ENDC 



BLISS ソース・ファイル (BLISS-32 または BLISS-64) の場合,VAX,EVAX,ALPHA,および IA64 マクロは ARCH_DEFS.REQ に定義されています。 Alpha では,EVAX と ALPHA は 1 に, VAX と IA64 は 0 に定義されています。 I64 では,IA64 は 1 に,VAX,EVAX,および ALPHA は 0 に定義されています。 BLISS の条件付きステートメントでこれらのシンボルを使用するには, ARCH_DEFS.REQ が必要です。

  注意
%BLISS(xxx),%TARGET(xxx),および %HOST(xxx) という構造は推奨されません。ただし,これらの構造を必ず変更しなければならないというわけではなく,必要に応じて変更すればよいと理解してください。

ソース・コードに以下のステートメントを追加します。

REQUIRE 'SYS$LIBRARY:ARCH_DEFS'; 

Alpha システムと I64 システムの両方で実行するには,以下のステートメントをソース・ファイルに追加してコードを条件付けします。

Alpha 固有のコードの場合:

%if ALPHA %then 
        . 
        . 
        . 
%fi 

I64 固有のコードの場合:

%if IA64 %then 
        . 
        . 
        . 
%fi 



C ソース・ファイルの場合,適切なプラットフォーム上のコンパイラで, __alpha__ALPHA__ia64,および __ia64__というシンボルが提供されます。シンボルはコンパイル・コマンド・ラインで定義できますが,この方法は推奨できません。また, arch_defs.hを使用して定義する方法も推奨できません。標準的な C のプログラミング手法では, #ifdefを使用します。

Alpha 固有のコードの場合:

#ifdef __alpha 
        . 
        . 
        . 
#endif 

I64 固有のコードの場合:

#ifdef __ia64 
        . 
        . 
        . 
#endif 



既存の条件付きコードは,変更が必要かどうか確認する必要があります。以下の BLISS のコードについて検討してみましょう。

%IF VAX %THEN 
  vvv 
  vvv 
%FI 
 
%IF EVAX %THEN 
  aaa 
  aaa 
%FI 

IA64 アーキテクチャ固有のコードを追加する必要がある場合は,以下のケースを追加します。

%IF IA64 %THEN 
  iii 
  iii 
%FI 

しかし,既存の VAX/EVAX 条件が実際には 64 ビットではなく 32 ビットを,あるいは OpenVMS の新規則ではなく旧規則 (たとえば,データ構造の拡張の有無や呼び出すルーチンの異同) を反映するのであれば,以下の条件付きコードの指定方法の方がより適切だと考えられます。これは,Alpha と I64 のコードは同じであり, 64 ビット・コードと VAX のコードとは区別する必要があるからです。

%IF VAX %THEN 
  vvv 
  vvv 
%ELSE 
  aaa 
  aaa 
%FI 



4.8.2 Alpha アーキテクチャに依存しているシステム・サービス

特定のシステム・サービスは,OpenVMS Alpha ではアプリケーション内で問題なく動作しても, I64 へのポーティングがうまくいかないことがあります。以降の項では,このようなシステム・サービスと,それに代わる I64 でのシステム・サービスを説明します。

OpenVMS Alpha では, SYS$GOTO_UNWIND システム・サービスは,プロシージャ起動ハンドルを 32 ビット・アドレスで受け取ります。このシステム・サービスを呼び出している箇所を 64 ビット・アドレス用の SYS$GOTO_UNWIND_64 に変更する必要があります。ソース・コードを変更して,プロシージャ起動ハンドルに 64 ビットの領域を割り当ててください。また,OpenVMS I64 の起動コンテキスト・ハンドルを返すライブラリ・ルーチンも,OpenVMS Alpha とは異なります。詳細については,『OpenVMS Calling Standard』を参照してください。

SYS$GOTO_UNWIND は,プログラミング言語機能をサポートする際によく使用されます。多くの場合は,コンパイラや実行時ライブラリでの変更になりますが, SYS$GOTO_UNWIND を直接使用している場合は,変更が必要です。

SYS$LKWSET および SYS$LKWSET_64 システム・サービスは変更されています。詳細については, 第 4.8.9 項 を参照してください。

4.8.3 Alpha アーキテクチャに依存するその他の機能を含むコード

Alpha でのコーディング手法には I64 で使用すると異なる結果になるものがいくつかあります。ここでは,そのためにアプリケーションを変更しなければならない場合について説明します。

初期化済みのオーバーレイ・プログラム・セクションの取り扱いは, Alpha と I64 とで異なります。 OpenVMS Alpha システムでは,オーバーレイ・プログラム・セクションの異なる部分を複数のモジュールで初期化することができます。このような初期化は,OpenVMS I64 システムでは認められていません。この動作の変更の詳細については, 第 5.3.1.2 項 を参照してください。

OpenVMS Alpha では,多くの算術演算エラー条件に対して SS$_HPARITH が通知されます。 OpenVMS I64 では,算術演算エラー条件に対して SS$_HPARITH が通知されることはありません。 OpenVMS I64 では,より細分化されたエラー・コード SS$_FLTINV と SS$_FLTDIV が通知されます。

これらの細分化されたエラー・コードを検出するように,条件ハンドラを更新してください。両方のアーキテクチャで共通のコードを使用するには,コードで SS$_HPARITH を参照している箇所において, OpenVMS I64 では SS$_FLTINV と SS$_FLTDIV も検出するように変更する必要があります。

OpenVMS I64 のメカニズム・アレイ・データ構造は, OpenVMS Alpha の場合と大きく異なります。戻り状態コード RETVAL は,Alpha プラットフォームと I64 プラットフォームの両方の戻り状態レジスタを表すように拡張されています。詳細については,『OpenVMS Calling Standard』を参照してください。

OpenVMS I64 システムで作成されるオブジェクト・ファイルの形式は Alpha の形式と異なるため,コードが Alpha のオブジェクト・ファイルのレイアウトに依存している場合は変更の必要があります。

オブジェクト・ファイルの形式は,『System V Application Binary Interface』 2001 年 4 月 24 日付けドラフトに記述されている ELF (Executable and Linkable Format) の 64 ビット版に準拠しています。このドキュメントは Caldera が発行しており,以下の Web サイトで入手できます。

http://www.caldera.com/developers/gabi 

また,オブジェクト・ファイルの形式は,『Intel® Itanium® Processor-specific Application Binary Interface (ABI)』 2001 年 5 月発行 (ドキュメント番号 245270-003) に記載されている I64 固有の拡張にも準拠しています。 OpenVMS オペレーティング・システム固有のオブジェクト・ファイルおよびイメージ・ファイル機能をサポートするのに必要な拡張や制限事項も将来のリリースで追加される予定です。

イメージ内のデバッガが使用する部分は, DWARF Version 3 業界標準に準拠しています。このドキュメントは以下の Web サイトで入手できます。

http://www.eagercon.com/dwarf/dwarf3std.htm 

OpenVMS I64 でのデバッグ・シンボル・テーブルの表現は,このドキュメントに記述されている業界標準の DWARF デバッグ・シンボル・テーブルの形式です。 DWARF Version 3 形式に対する HP の拡張については,将来のリリースで公開される予定です。


目次 索引

© 2012 Hewlett-Packard Development Company, L.P.